LASTE LAOS J W ^ G G К PRDGRAMING GRAFICA WINDOWS Win GDI și DirectDraw Feng Yuan Compania Hewlett Packard inventar www hp com/hpbooks PH PTR Prentice Hali PTR Upper Saddle River, New Jersey www phptr com Fen Yuan Programare grafică pentru Windows MASTER-CLASS C^PPTER Sankt Petersburg • Moscova • Harkov • Minsk Fen Yuan Programare grafică pentru Windows Tradus din engleză de E Matveev Redactor-șef Redactor-șef Manager de proiect Editor științific Editor literar Artist ilustrativ Coritor de corecturi Aspect E Stroganova I Korneev A Vasiliev E Matveev A Zhdanov N Birzhakov V Shenderova V Listova Y Sergienko BBK - UDC Yuan Feng Programare grafică Yu pentru Windows (+CD) - Sankt Petersburg: Petru, - p : ill ISBN - - - Cartea este dedicată programării grafice pentru Windows folosind Win GDI API De asemenea, oferă o introducere în DirectDraw și o scurtă introducere în modul imediat Direct D Acesta acoperă caracteristicile standard acceptate pe toate platformele Win , caracteristicile pe de biți care erau disponibile numai pe Windows NT/ și cele mai recente extensii GDI care au fost introduse doar în Windows și Windows Cartea conține multe fragmente de cod care sunt potrivit pentru utilizare practică Pe lângă cele mai simple programe de testare și demonstrație, veți găsi multe funcții, clase C++, drivere, utilitare și programe non-triviale care sunt destul de potrivite pentru utilizarea în proiecte comerciale CD-ul conține codul sursă complet, fișiere de spațiu de lucru Microsoft Visual C++, binare precompilate (versiuni de depanare și finale) și fișiere JPEG pentru capitolele despre algoritmul grafic Ediție originală în limba engleză Copyright © de către compania Hewlett-Packard © Traducere în rusă, E Matveev, © Editura Piter, Drepturi de publicare obținute în baza unui acord cu Prentice Hali, Inc Toate drepturile rezervate Nicio parte a acestei cărți nu poate fi reprodusă sub nicio formă fără permisiunea scrisă a deținătorilor drepturilor de autor Informațiile conținute în această carte au fost obținute din surse considerate de către editor a fi de încredere Cu toate acestea, din cauza unor posibile erori umane sau tehnice, editorul nu poate garanta acuratețea și caracterul complet al informațiilor furnizate și nu este responsabil pentru eventualele erori asociate cu utilizarea cărții ISBN - - - ISBN - - - CJSC „Peter Buk” , Sankt Petersburg, str Blagodatnaya, ID licență nr din Beneficiu fiscal - clasificator integral rusesc al produselor OK - , volumul ; - cărți și broșuri Semnat pentru publicare la Format x / Conv p l , Tiraj de exemplare Ordinul nr Tipărit din folii transparente la Întreprinderea Unitară Federală de Stat „Printing Yard” numită după A I A M Gorki de la Ministerul Federației Ruse pentru Presă, Televiziune și Radiodifuziune și Comunicații de Masă , Sankt Petersburg, pr Chkalovsky, rezumat Capitolul Capitolul Arhitectura grafică Windows Capitolul Structuri interne de date GDI/DirectDraw Capitolul : Monitorizarea sistemului grafic Windows Capitolul Abstracția dispozitivului grafic Capitolul Capitolul Pixeli Capitolul Capitolul Capitolul Înțelegerea rasterelor Capitolul Capitolul Grafică Windows și hărți de biți bbz Capitolul Capitolul Capitolul Capitolul Metafișiere Capitolul Tipărire Capitolul Modul Direct D yoo Index alfabetic Conţinut Mulțumiri Introducere Despre ce este această carte Cum este organizată această carte Cum să citești această carte Ce este pe CD Ce urmeaza? De la editor Capitolul Principii și concepte de bază Elementele fundamentale ale programării Windows în C/C++ Hello World Versiunea : Lansarea browserului Hello World Versiunea : Afișarea textului pe desktop Hello World Versiunea : Crearea unei ferestre pe ecran complet Bună ziua, Versiunea mondială: Ieșire DirectDraw Asamblator Mediul de programare Dezvoltare și testare Compilatoare Microsoft Platform SDK Kit de dezvoltare a driverelor Microsoft Microsoft Developer Network Format de fișier executabil Win Director de import Export director Arhitectura sistemului de operare Microsoft Windows HAL Microkernel Drivere de dispozitiv Sistem de management al ferestrelor și grafică Partea executivă Funcțiile sistemului Procesele de sistem Servicii Subsisteme platforme Rezultate Exemple de programe Conţinut Capitolul Arhitectura grafică Windows Componente grafice Windows Multimedia Video pentru Windows Imagine statica OpenGl Windows media Componente în modul Kernel Drivere pentru modul Kernel Arhitectura GDI Funcții exportate de la GDI DLL Grupuri de funcții GDI Apeluri de funcții ale sistemului GDI De la Win GDIAPI la Funcțiile sistemului motor GDI Arhitectura DirectX Componente DirectX Arhitectura DirectDraw Arhitectura sistemului de imprimare Client Win Spooler Serviciu de spool Spooler Router Furnizor de imprimare Procesor de imprimare Monitorizare limbă și monitorizare porturi În interiorul procesului Spooler Mecanism grafic Funcțiile sistemului motorului grafic Motor de randare grafică Structuri de date ale motorului grafic Convertirea în primitive Drivere de font Drivere de ecran Driver pentru portul video și driverul pentru portul mini video Atribuirea driverului de afișare Inițializarea driverului de afișare Refacerea la suprafață, interceptarea și întoarcerea Caracteristici avansate ale driverului Suport DirectDraw/Direct D la nivelul driverului de afișare Drivere de imprimantă Drivere Microsoft de control al imprimantei opt Conţinut DLL de grafică a driverului de imprimantă Driver de imprimantă pentru ieșirea documentelor HTML Rezultate Exemple de programe Capitolul Structuri interne de date GDI/DirectDraw Manipulatoare și programare orientată pe obiecte Clasa si obiect Implementare Încapsulare și Mascare Indicatori și manipulatori Afișarea identității Afișare tabelară Când manipulatorul nu este suficient Înțelegerea manipulatorilor de obiecte GDI Manipulatoare standard de obiecte - Constante HGDIOBJ nu este un pointer Număr maxim de manipulatoare GDI la nivelul procesului — Număr maxim de manipulatoare GDI la nivel de sistem - Partea HGDIOBJ conține un index Partea HGDIOBJ conține tipul obiectului GDI Găsirea tabelului de obiecte GDI Descifrarea tabelului de obiecte GDI Pointerul pKernel se referă la pool-ul paginat Câmpul nCount este uneori folosit ca număr de selecție a obiectelor Câmpul nProcess asociază un handle GDI cu un proces specific nllpper: verificare suplimentară nType: tip de obiect intern pUser: pointer către structura de date în modul utilizator Structuri de date în modul utilizator Structura de date în modul utilizator perii: optimizarea creării pensulelor uniforme Structura de date în modul utilizator pentru regiuni: optimizarea regiunilor dreptunghiulare Structura de date în modul utilizator pentru fonturi: Tabel cu valori de lățime Structura datelor în modul utilizator pentru contextul dispozitivului: atribute Accesarea spațiului de adresă în modul Kernel Conţinut nouă WinDbg și extensia GDI Debugger Structuri de date în modul kernel Tabelul obiectelor GDI din motorul GDI Tipuri de obiecte GDI în motorul GDI Contextul dispozitivului în motorul GDI Structura PDEV în mecanismul GDI Suprafețele din motorul GDI Rastere dependente de dispozitiv în motorul GDI Secțiuni DIB din motorul GDI Perii în motorul GDI Pixuri în motorul GDI Paletele din motorul GDI Regiunile din motorul GDI Trasee de scule în motorul GDI Fonturi în motorul GDI Alte obiecte GDI din motorul GDI Structuri de date DirectDraw Rezultate Exemple de programe Capitolul Monitorizarea sistemului grafic Windows Urmărirea apelurilor de funcție API Win Crearea unui program de monitorizare Injectarea DLL-ului Scout Conectarea la lanțul de apeluri al funcției API Colectarea de informații Ieșire de date Program de control Urmărirea apelurilor Win GDI Fișierul de definiție API GDI Decodor de date GDI Monitorizare completă API Urmărirea interfețelor COM DirectDraw Tabelul funcțiilor virtuale Definiția DirectDraw API Modificarea tabelului de funcții virtuale Urmărirea apelurilor de sistem GDI Monitorizarea interfeței DDI Rezultate Exemple de programe Conţinut Capitolul Abstracția dispozitivului grafic Adaptoare video moderne Frame Buffer Format pixel Buffering dublu, z-buffer și texturi Accelerație hardware Lista de dispozitive și moduri de pe ecran Contextul dispozitivului Crearea unui context de dispozitiv Obținerea de informații despre capacitățile dispozitivului Atribute în contextul dispozitivului Asocierea unui context de dispozitiv cu o fereastră Ieșire grafică într-un mediu cu mai multe ferestre Obținerea contextului dispozitivului asociat cu o fereastră Context dispozitiv partajat Contextul dispozitivului de clasă Contextul dispozitivului privat Contextul dispozitivului părinte Alte contexte de dispozitiv Contextul informaţiilor despre dispozitiv Context Dispozitiv compatibil Contextul dispozitivului metafișier Reprezentarea formală a unui context de dispozitiv Exemplu: Clasă de fereastră de cadru generică Clasa barei de instrumente Clasa bară de stare Clasa de pânză Clasa de ferestre cadru Programul de testare Exemplu de program: Trasarea în contextul dispozitivului Regiunea ferestrei actualizată Mesaj WM PAINT Vizualizarea mesajelor de redesenare a ferestrei Rezultate Exemple de programe Capitolul Sisteme de coordonate și transformări Sistemul de coordonate fizice Sistemul de coordonate al dispozitivului Sistemul de coordonate ale paginii și modurile de afișare Mod de afișare MM TEXT Conţinut unsprezece Moduri de afișare MM LOENGLISH și MM HIENGLISH Moduri de afișare MM LOMETRIC și MMJ-IIMETRIC Mod de afișare MM TWIPS Mod de afișare MM-ISOTROPIC Mod de afișare MM ANISOTROPIC Puncte de bază ale ferestrelor și ferestrelor Alte funcții ale ferestrei și zonei de vizualizare Sistemul mondial de coordonate Transformări afine Funcții de transformare a lumii în API-ul Win Utilizarea transformărilor lumii Utilizarea sistemelor de coordonate Implementarea transformărilor în GDI Exemplu de program: Defilare și mărire Jucând Go în clasa KScrollCanvas Rezultate Exemple de programe Capitolul Pixeli Obiecte GDI, manipulatoare și tabelul de obiecte Stocarea obiectelor GDI Tabel de obiecte GDI Manipulator de obiecte GDI API-ul obiectelor GDI Detectarea scurgerilor de obiecte GDI Decuparea Transportor de tăiere Regiuni simple Regiunea delimitată Meta regiune Cele cinci regiuni de context pentru dispozitive Vizualizarea regiunilor în contextul dispozitivului Culoare Spațiu de culoare RGB Spațiu de culoare HLS Culori și palete indexabile Posibilitati non-triviale Ieșire pixeli Exemplu: Mulțimea Mandelbrot Rezultate Exemple de programe Conţinut Capitolul Linii și curbe Operații raster binare Modul de umplere a fundalului și culoarea de fundal Pene Obiect stilou logic Pene standard Pene simple Pene extinse Obținerea informațiilor despre stilourile logice Clasă pentru lucrul cu obiecte stilou GDI Linii Curbele Bezier PolyDraw Definiție alternativă a curbelor Bezier Arcuri Determinarea unui arc în grade: Funcția AngleArc Desenarea arcurilor cu stilul stilou PS INSIDEFRAME Conversia arcurilor în curbe Bezier Traiectorii Construcţia traiectoriei Obţinerea informaţiilor despre traiectorie Transformarea obiectului traseului de instrumente Operaţii grafice utilizând trasee de instrumente Convertirea unei căi într-o regiune Exemplu: Desenarea liniilor de stil personalizate Rezultate Exemplu de program Capitolul Perii Obiect perie logică Perii standard Pensule personalizate Pensule de culoare sistem Structura LOGBRUSH Dreptunghiuri Dreptunghi ca structură de date Desen dreptunghiuri Desenarea chenarelor și controalelor Elipse, sectoare, segmente și dreptunghiuri rotunjite Conţinut Poligoane Modul de umplere poligon Căi închise Regiunile Crearea unui obiect regiune Operații cu obiecte ale regiunilor Desenarea regiunilor Umpleri cu degrade Dreptunghiuri de umplere cu gradient Aplicarea umplerilor cu degrade pentru a crea butoane D Utilizarea practică a umpluturii Umplere semitransparentă Implementarea umplerilor cu degrade în spațiul de culoare HLS Umpleri cu gradient radial Texturi și umpleri bitmap Umplerea modelului Rezultate Exemplu de program Capitolul Înțelegerea rasterelor Rastere independente de dispozitiv Format de fișier BMP Raster împachetat independent de dispozitiv Raster împărțit independent de dispozitiv Clasa pentru lucrul cu DIB Afișarea DIB-ului în contextul dispozitivului StretchDIBits Dreptunghi sursă Recepție dreptunghi și moduri de scalare Conversie format de culoare Operare raster Exemplu de funcție StretchDIBits SetDIBitsToDevice Contexte de dispozitive compatibile Rastere dependente de dispozitiv Creați o hartă de biți CreateBitmapIndirect GetObject și DDB CreateCompatibleBitmap și CreateDiscardableBitmap Creați DIBitmap LoadBitmap paisprezece Conţinut Copierea hărților de biți între formatele DIB și DDB Acces direct la matricea de pixeli DDB Utilizarea rasterelor DDB Afișarea rasterelor DDB Utilizarea ecranelor din meniu Utilizarea unei hărți de bit ca fundal de fereastră CreateDIBSection Clasa de lucru cu secțiuni DIB Funcțiile GetObjectType și GetObject pentru secțiuni DIB GetDIBColorTable și SetDIBColorTable Utilizarea secțiunilor DIB: Ieșire independentă de dispozitiv Utilizarea secțiunilor DIB: Ieșire de înaltă rezoluție Rezultate Exemple de programe Capitolul Operații cu raster ternar Coduri de operare raster Diagrama operațiilor raster ternar Operații raster utilizate în mod obișnuit Rastere transparente Funcția PlgBIt Operații de bitmap cuaternar: MaskBIt Taste de culoare: TransparentBIt Transparență fără mască Ieșire transparentă utilizând forme geometrice Ieșire transparentă utilizând tăierea Pregătirea imaginilor Suprapunere alfa Exemplu de suprapunere alfa cu rată constantă Apariția și ieșirea din ecrane Ferestre transparente Alpha Channel: Clasa AirBrush Simularea suprapunerii alfa Rezultate Exemple de programe Capitolul Grafică Windows și hărți de biți Acces direct la pixeli Transformări afine ale rasterelor Transformări Raster Personalizate rapide Conţinut cincisprezece Conversii de culoare Conversia bitmap-urilor în tonuri de gri Corecție gamma Conversia pixelilor în raster Clasa generică de transformări pixeli Clasă generică de separare a culorilor Exemplu de extragere a canalului Grafic de bare Filtre spațiale Filtre de netezire și ascuțire Alegerea granițelor și terenului Filtre morfologice Rezultate Exemple de programe Capitolul Palete Paleta de sistem Opțiuni pentru ecran Obținerea paletei de sistem Culori statice Paleta logică Paleta implicită Paleta de semitonuri Crearea unei palete personalizate Mesaje din paletă WM QUERYNEWPALETTE WM PALETTEISCHANGING WM PALETTECHANGED Programul de testare Paleta și rasterele Rastere și palete dependente de dispozitiv Rastere și palete independente de dispozitiv Indexul paletei în tabelul de culori DIB Secțiuni și paletă DIB Cuantificarea culorilor Reducerea adâncimii de culoare a unui ecran Rezultate Exemplu de program Capitolul Fonturi Ce este un font? Seturi de caractere și codificări Conţinut Glife Font Familie de fonturi și stil Fonturi bitmap Fonturi vectoriale Fonturi TrueType Format de fișier cu font TrueType Antet font Profil maxim Maparea caracterelor la indici glifi Tabel index Date Glyph Instrucțiuni pentru glif Metrici orizontale Kerning Valori OS/ și Windows Alte tabele Colecții TrueType Instalarea și încorporarea fonturilor Fișiere cu resurse de font Instalarea fonturilor publice Instalarea fonturilor proprietare și a mai multor fonturi OpenType Mașter Instalarea fonturilor dintr-o imagine de memorie Încorporarea fonturilor Tabel cu fonturi de sistem Rezultate Exemple de programe Capitolul Fonturi logice Valorile fonturilor în Windows Fonturi standard Crearea fonturilor logice Înlocuirea fontului Sistemul de înlocuire a fonturilor PANOSE Obținerea de informații despre un font logic Valori pentru font raster și vector Valorile fonturilor TrueType/OpenType Structura LOGFONTb a metricii fontului Precizia valorilor fonturilor Conţinut Ieșire simplă de text Alinierea textului Ieșire text de la dreapta la stânga Intervale suplimentare Lățimea simbolului Ieșire de text non-trivială Conversia caracterelor în glife Kerning Aranjamentul caracterelor Funcția ExtTextOut Uniscrie Accesarea datelor Glyph Formatarea textului Ieșire text cu file Formatare simplă a paragrafelor Formatarea textului independentă de dispozitiv Efecte de ieșire a textului Culoarea textului Inscripții Efecte geometrice Lucrul cu text în format raster Textul ca o colecție de curbe Text ca regiune Rezultate Exemplu de program Capitolul - Metafișiere Înțelegerea metafișierelor Crearea unui metafișier îmbunătățit Redare îmbunătățită a metafișierului Preluarea informațiilor despre un metafișier îmbunătățit Transferarea metafișierelor îmbunătățite Structura metafișierelor extinse Înregistrări EM Clasificarea tipurilor de înregistrări EMF Descifrarea înregistrărilor EMF Obiecte GDI simple în EMF Rastere în EMF Regiunile din CEM Traiectorii în EMF Palete în EMF optsprezece Conţinut Sisteme de coordonate în EMF Comenzi de ieșire în EMF Independenţa hardware EMF Enumerarea înregistrărilor EMF Clasa C++ pentru enumerarea intrărilor EMF Redare cu încetinitorul EMF Urmă de redare EMF EMF dinamică Construirea de metafișiere derivate EMF ca instrument de programare Decompilator EMF Salvarea fișierului Spooler EMF Rezultate Informatii suplimentare Exemple de programe * Capitolul Tipărire Cunoaștere cu spooler Procesul de imprimare Limbajul de control al imprimantei Ieșire directă către port Imprimarea cu Spooler Procesor de imprimare EMF Enumerarea imprimantei Obținerea informațiilor despre imprimantă Configurare driver de imprimantă Imprimare GDI de bază Casete de dialog de tipărire standard Crearea unui context de dispozitiv de imprimantă Obținerea informațiilor despre contextul dispozitivului de imprimantă Secvență pentru generarea lucrărilor de imprimare Suport pentru imprimarea în programe Sistem de coordonate logic unificat Simularea aspectului unei pagini Ieșire simultană a paginii Imprimarea mai multor pagini pe o singură coală Clasa generică de sigiliu Ieșire în contextul unui dispozitiv de imprimantă Unități Text Conţinut nouăsprezece Rasterele Imprimarea graficelor în format JPEG Rezultate Informatii suplimentare Exemple de programe Capitolul DirectDraw și Direct D Imediate Mode iooo Tehnologia COM Interfețe COM Clasele COM Crearea unui obiect COM REZULTATELE DirectX și COM Înțelegerea DirectDraw Interfață IDirectDraw Interfață IDirectDrawSurface Ieșire de suprafață DirectDraw Alegerea culorilor Interfața IDirectDrawClipper Fereastra simplă DirectDraw Construirea bibliotecii grafice DirectDraw Ieșire pixeli Ieșire de linie Umplerea zonelor închise Decuparea Suprafețe în afara ecranului Sprijinirea transparenței cu taste de culoare Font și text Sprites Modul Imediat Direct D Pregătirea mediului Direct D Direct Mode Redimensionarea unei ferestre Ieșire în două trepte Utilizarea Direct D într-o fereastră Suprafeţe texturate Exemplu de utilizare a modului Direct D Direct Rezultate Exemple de programe Index alfabetic Cu dragoste și recunoștință, dedic această carte părinților mei mamei mele și amintirii binecuvântate a tatălui meu, precum și locuitorii orașului meu natal, Suzhou Oriental Garden Mulțumiri Această carte nu ar fi fost niciodată posibilă fără ajutorul, încurajarea și sprijinul multor oameni, cărora le sunt sincer recunoscător Vreau să mulțumesc editorului de presă HP, Susan Wright, și lui Prentice Hali, editorului PTR, JilI Pisoni, pentru că au avut încredere într-un programator necunoscut pentru a scrie o carte de de pagini, care în cele din urmă a crescut la de pagini și iertarea eventualelor întârzieri La Prentice Hali PTR, editorul principal James Markham și editorul principal Faye Gemmelaro au oferit îndrumări valoroase cu privire la structura cărții și prezentarea informațiilor tehnice, au sugerat noi modalități de prezentare a materialului, au îmbunătățit stilul autorului și au ajutat la găsirea și rezolvarea multor probleme Hewlett Packard are un program minunat care oferă unui angajat care dorește să scrie o carte tehnică cu suport organizațional de la HP Mulțumesc șefului meu și inspirației pentru această carte, Ivan Crespo, pentru sprijinul său continuu pe parcursul cărții Acum patru ani, m-am mutat la laboratorul de cercetare și dezvoltare Hewlett-Packard din Vancouver, unde au fost dezvoltate imprimantele HP Deskjet de renume mondial cu niște abilități de programare Winl Am învățat atât de multe din studierea codurilor sursă, discutarea și certurile cu colegii, programarea și urmărirea codului de asamblare în SoftICE/W, încât după un an și jumătate am decis să contactez HP Press și să propun acest proiect Sunt recunoscător oamenilor de la Hewlett-Packard Research Lab din Vancouver pentru tot ce am învățat de la ei și pentru sprijinul lor Trec la cele mai importante Îi sunt veșnic recunoscătoare soției mele Yin Peng pentru că m-a crezut, m-a înțeles și m-a susținut în timpul lungilor mele bătălii cu GDI în weekend, seara și chiar noaptea Fiul nostru, Chao Chu, a încercat și el să ajute și s-a uitat la ecranul monitorului în fiecare seară înainte de a merge la culcare În sfârșit, voi avea timp liber și vara aceasta cu siguranță vom finaliza construcția robotului său subacvatic Fen Yuan Introducere O nouă carte despre programare pentru Windows va fi utilă doar dacă conține informații profunde, complete, actualizate, de încredere și practice Cartea profundă nu se oprește la nivelul API, ci se scufundă în concepte arhitecturale, structuri de date interne și principii de implementare a API În plus, ar trebui să ofere cititorului mijloacele pentru cercetare independentă Cartea completă și actualizată se concentrează pe cea mai bună implementare actuală a API-ului Win , Windows , baza viitoarelor sisteme de operare ale Microsoft, și descrie noile sale caracteristici Această carte de încredere se bazează pe studii experimentale ale API-ului Win și pe verificarea atentă a tuturor informațiilor Este imposibil să începeți doar de la documentația Microsoft, deoarece descrie interfața abstractă Win API și adesea întâlnește informații incomplete, învechite și inexacte Cartea practică depășește o simplă descriere a API-ului și exemple explicative banale Se concentrează pe sarcini practice; conține cod de program care poate fi utilizat în programe reale; oferă cititorului utilități utile și îl ajută să scrie programe profesionale După cum știți, Win GDI (și programarea grafică pentru Windows în general) este una dintre pietrele de temelie ale oricărui program Windows Există multe cărți dedicate acestui subiect, dar întreaga comunitate de programatori care lucrează adesea cu Windows GDI are nevoie cu siguranță de informații mai profunde, mai complete, mai actualizate, mai fiabile și mai practice Aceste obiective au fost ghidate de autor când a scris cartea Despre ce este această carte Despre ce este această carte Cartea este dedicată programării grafice pentru Windows folosind Win GDI API De asemenea, oferă o introducere în DirectDraw și o introducere și mai scurtă în modul direct al Direct D Acesta acoperă caracteristicile standard acceptate pe toate platformele Win , caracteristicile pe de biți care erau disponibile numai pe Windows NT/ și cele mai recente extensii GDI care au fost introduse doar în Windows și Windows În special, o descriere completă a alpha suprapunere, blitting transparent, umplere în gradient, text în partea dreaptă, ferestre transparente și trimiterea de imagini JPEG/PNG la o imprimantă Cartea oferă cititorului o bună înțelegere a modului în care funcționează sistemul grafic Windows și îl învață cum să folosească API-ul Win cu mai multă încredere și mai eficient Cartea învață că orice documentație Win necesită o abordare analitică și critică În primul rând, trebuie să înțelegeți după ce logica s-au ghidat dezvoltatorii, iar experimentele și bunul simț vă vor ajuta să înțelegeți mai bine API-ul Win , să găsiți singur informațiile lipsă sau erorile din documentație Cartea vă va învăța cum să utilizați eficient utilitățile care vă ajută să înțelegeți mai bine API-ul Win Mai important, vă va învăța cum să creați singur astfel de utilități (folosind adesea trucuri ingenioase de programare a sistemului) și cum să experimentați cu aspecte interesante nedocumentate ale API-ului Win Câteva capitole inițiale oferă informații generale despre funcționarea internă a sistemului, aplicabile altor domenii ale programării Windows Cartea conține multe fragmente de cod potrivite pentru utilizare practică Pe lângă cele mai simple programe de testare și demonstrație, veți găsi multe funcții, clase C++, drivere, utilitare și programe non-triviale care sunt destul de potrivite pentru utilizarea în proiecte comerciale Cartea dezvoltă o bibliotecă întreagă de clase C++ cu care puteți lucra cu ferestre simple, ferestre SDI și MDI, casete de dialog standard și personalizate, bare de instrumente, bare de stare etc Clasele incluse în bibliotecă facilitează lucrul cu bitmap-uri DIB , DDB bitmaps și secțiuni DIB, randare EMF, aplicarea algoritmilor bitmap, cuantificarea culorilor, codificarea/decodarea imaginilor JPEG, decodarea fișierelor font, înlocuirea fonturilor prin metrici PANOSE, ieșire glif, construirea textului volumetric etc d Programele din această carte nu depind de MFC (Microsoft Foundation Classes) sau de orice alte biblioteci de clasă, așa că pot fi utilizate în orice program C++ Toate numele claselor încep cu un prefix „K”, astfel încât să le puteți utiliza în MFC, ATL, OWL sau în biblioteca personală a clasei Introducere Cum este organizată această carte Programarea grafică pentru Windows este luată în considerare la trei niveluri: nivelul de implementare, nivelul API și nivelul aplicației Stratul de implementare include totul din culisele interfețelor Win GDI API și DirectX COM, lumea nedocumentată a motorului grafic și DLL-urile client ale subsistemelor Windows Materialul prezentat în capitolele , și oferă o bază solidă pentru înțelegerea nivelului API Nivelul API oferă o descriere clară, precisă și consecventă a API-ului Win GDI, precum și (deși mai puțin pronunțat) DirectDraw și modul imediat Direct D Stratul de aplicație este situat deasupra stratului API Include rezolvarea problemelor practice, crearea de funcții potrivite pentru reutilizare, clase C++ și programe non-triviale La prezentarea materialului, nivelul API este împletit cu nivelul aplicației De obicei, fiecare capitol începe cu o descriere a nivelului API și apoi trece la exemple practice Când se prezintă un material deosebit de complex (de exemplu, descrieri ale rasterelor), materialul teoretic principal este prezentat într-un singur capitol, iar aplicațiile sale netriviale sunt prezentate în capitolele următoare Capitolul , Fundamente și concepte, acoperă conceptele de bază de programare Windows utilizate în întreaga carte Acesta oferă o privire de ansamblu asupra programării Windows, limbajul de asamblare al procesorului Intel, mediul de programare, formatul de fișier executabil Win și arhitectura sistemului de operare Windows Partea mea preferată este conectarea simplă a funcțiilor API prin modificarea directoarelor de import/export din modulele Win Capitolul , Arhitectura grafică Windows, oferă o privire de ansamblu asupra sistemului grafic Windows, de la diferitele DLL-uri ale subsistemului Win până la driverele de dispozitive grafice Acesta acoperă componentele grafice Windows, arhitectura GDI, arhitectura DirectX, arhitectura subsistemului de imprimare, motorul grafic, driverele de afișare și de imprimantă În opinia mea, cea mai interesantă parte a acestui capitol este descrierea funcțiilor sistemului care combină implementarea GDI în modul utilizator cu motorul grafic în modul kernel, un utilitar pentru compilarea unei liste de apeluri către funcții de sistem nedocumentate (în GDI DLL, USER DLL, NTDLL DLL și WIN K SYS) și un driver simplu de imprimantă care generează pagini HTML cu hărți de biți încorporate Capitolul , „Structurile interne de date ale GDI/DirectDraw”, se citește ca o poveste polițistă sau o carte de vânătoare de comori Capitolul începe prin a explica paradigma de programare orientată pe obiecte Win bazată pe utilizarea manipulatoarelor Apoi încercăm să ne dăm seama care este mânerul obiectului GDI, trecem la găsirea tabelului de obiecte GDI și descifrarea lui În cele ce urmează, se descrie ierarhia complexă a structurilor de date utilizate în funcționarea interioară a sistemului grafic Windows Căutările din tabelul de obiecte GDI folosesc fișiere de depanare simbolice, utilitare scrise special și depanatorul Visual C++ Vom scrie chiar și un driver de dispozitiv pentru a citi datele din spațiul de adrese în modul kernel Cum este organizată această carte Programul Fosterer scris pentru Capitolul folosește extensia de depanare Microsoft pentru a decoda tabelul de obiecte GDI și structurile de date interne ale motorului grafic DirectX — toate pe aceeași mașină! Nu ratați această șansă și asigurați-vă că încercați Fosterer pe un computer Windows NT sau Cu toate acestea, mai întâi va trebui să instalați fișierele de depanare cu nume simbolice și depanatorul WinDbg Luați în considerare descrierea structurilor de date interne ca un fel de referință pentru a vă ajuta să înțelegeți procesul de depanare la nivel DDI, deoarece detaliile de implementare pot varia în funcție de versiunea sistemului de operare și chiar de versiunea Service Pack Puteți sări peste orice secțiune care nu pare suficient de interesantă și să reveniți la ea când aveți nevoie de mai multe informații, cum ar fi pentru a înțelege mai bine utilizarea resurselor de către obiectele GDI sau problemele de performanță Capitolul , Monitorizarea sistemului grafic Windows, prezintă diverse tehnici și instrumente pentru monitorizarea subsistemului grafic și a sistemului Windows în ansamblu Veți învăța cum să vă injectați DLL-urile în procese externe, cum să vă conectați la lanțul de apeluri API, cum să monitorizați și să interceptați apelurile funcției API Win , cum să interceptați apelurile funcției de sistem și metodele de interfață COM și, în sfârșit, apelurile de funcții ale interfeței DDI în modul kernel Subiectele mele preferate sunt scrierea de stub-uri în asamblator, interceptarea apelurilor intra-modul, apelurile la funcțiile de sistem și funcțiile DDI; toate acestea oferă o idee despre cum funcționează de fapt sistemul Capitolul este pentru programatorul experimentat; dacă încă nu ai nevoie de el, sări peste el Capitolul , Graphics Device Abstraction, începe cu o descriere a funcțiilor API de programare grafică Windows și exemple de aplicare practică a acestora Capitolul acoperă adaptoarele video, bufferele de cadre, obiectele contextului dispozitivului, clasa generică a ferestrei de cadre și ieșirea cu ferestre Subiectul meu preferat este programul WinPaint, care oferă o reprezentare vizuală a mesajelor de redesenare a ferestrelor Capitolul , Sisteme de coordonate și transformări, discută cele patru sisteme de coordonate suportate de GDI, maparea fereastră-la-vizualizare, transformările lumii (afine) și rolul lor în derulare și mărire În timp ce scriam această carte, nu am apucat să joc jocul meu preferat de masă, weichi, așa că pentru capitolul am scris un program simplu care desenează o tablă weichi Capitolul , Pixeli, oferă o scurtă prezentare generală a obiectelor GDI, a mânerelor și a tabelului de obiecte la nivelul API-ului GDI Următorul este un program cu care puteți monitoriza utilizarea manipulatoarelor GDI la nivel de sistem Din regiuni, trecem la mecanismul de tăiere, spațiile de culoare și ieșirea pixelilor individuali, iar în final vom scrie un program pentru a scoate seturile Mandelbrot Cea mai utilă parte a acestui capitol este o descriere a regiunilor de sistem, a metaregiunilor, a regiunilor de tăiere și a regiunilor Rao utilizate în decupare, precum și a programului ClipRegion pentru a le vizualiza Capitolul , Linii și curbe, acoperă operațiuni raster binare, moduri de umplere a fundalului, culori de fundal, obiecte stilou logic, Introducere linii, curbe Bezier, arce, trasee și linii de stil care nu sunt suportate direct de GDI În opinia mea, acest capitol merită să acordăm atenție calculelor matematice asociate conversiei curbelor eliptice în curbe Bezier Capitolul , Regiuni închise, descrie pensule, dreptunghiuri, elipse, felii și segmente de plăcintă, dreptunghiuri rotunjite, poligoane, trasee închise, regiuni, umpleri cu gradient și diverse tehnici de umplere a formelor închise utilizate în aplicațiile grafice Un interes deosebit este utilizarea umpluturilor cu gradient pentru desenarea butoanelor tridimensionale și descrierea structurilor acestor regiuni Capitolul , Înțelegerea rasterelor, discută cele trei formate de raster acceptate de GDI — rastere independente de dispozitiv (DIB), rastere dependente de dispozitiv (DDB) și secțiuni DIB Acest capitol descrie clase pentru lucrul cu secțiuni DIB, DDB și DIB, contexte de dispozitiv compatibile și utilizări standard pentru aceste formate bitmap Acordați atenție claselor, în special folosirii secțiunilor DIB pentru redarea EMF independentă de dispozitiv Capitolul II, „Utilizări non-triviale ale bitmap-urilor”, discută operațiunile bitmap ternare, redarea bitmap-urilor transparente, implementarea transparenței fără aplicarea de măști, maparea alfa și una dintre noile caracteristici ale Windows , ferestre transparente Partea mea preferată este descrierea completă a operațiilor raster și simularea operațiunilor raster cuaternare folosind câteva operații ternare Capitolul , „Grafica și rastere Windows”, descrie accesul direct la pixeli, transformările raster afine, transformările de culoare și pixeli și filtrele spațiale Capitolul , Palete, acoperă paletele de sistem și logice, mesajele paletei, paletele în hărți de biți, cuantificarea culorilor și distribuția erorilor, reducând în același timp numărul de culori Implementarea de mai sus a algoritmului de cuantificare a culorii arborelui octant construiește adesea o paletă mai bună decât aplicațiile comerciale Capitolul , Fonturi, acoperă seturi de caractere, codificări, glife, fonturi, familii de fonturi, fonturi bitmap și vector, fonturi TrueType, instalarea fonturilor în sistem și încorporarea acestora în documente Material deosebit de interesant este oferit în secțiunea despre formatul de fișier intern al fonturilor TrueType Capitolul , Text, tratează fonturile logice, înlocuirea fonturilor, sistemul PANOSE, valorile textului, textul simplu și complex, formatarea și efectele de ieșire a textului Ultimul subiect merită o atenție deosebită; veți învăța cum să suprapuneți o imagine bitmap pe textul de ieșire, cum să creați umbre și să simulați relieful, cum să afișați textul oblic și vertical, cum să plasați caractere de-a lungul unei curbe, cum să convertiți textul într-un bitmap sau un contur și cum pentru a crea cel mai simplu text tridimensional Capitolul , Metafișiere, discută procesul de creare și redare a metafișierelor, structura lor internă și specificul injectării obiectelor GDI în ele Vă veți familiariza cu decodificarea EMF, enumerarea înregistrărilor, Cum să citești această carte decompilarea și salvarea datelor spooler în format EMF După părerea mea, cel mai interesant lucru din acest capitol este decompilatorul EMF și programul EMFScope, conceput pentru a salva fișierele spooler în Windows / Capitolul , „Imprimare”, acoperă spooler-ul, imprimarea GDI de bază, suportul aplicației pentru imprimare, ieșirea grafică JPEG (inclusiv trimiterea JPEG-urilor direct la driverul imprimantei) și tipărirea programelor C++ cu evidențiere de sintaxă Cel mai interesant lucru din acest capitol este un set de clase generice pentru afișarea mai multor pagini în același timp, indiferent de rezoluția și scara dispozitivului Aceste clase sunt utilizate atât de programul de ieșire JPEG, cât și de programul de ieșire sursă Capitolul , „Modul imediat DirectDraw și Direct D”, oferă un curs introductiv de programare DirectX pentru programatori GDI experimentați Introduce elementele de bază ale COM, oferă clase pentru mediul DirectDraw și suprafețele DirectDraw Descrie cele trei metode de randare DirectDraw, obiecte de tăiere, suprafețe în afara ecranului și redarea textului DirectDraw De asemenea, sunt incluse clase pentru operațiunile de bază în modul imediat Direct D, tamponarea dublă, manipularea texturii și ferestrele activate pentru DirectDraw Partea mea preferată este utilizarea GDI pentru a crea fonturi DirectDraw care redă textul eficient pe suprafețele DirectX Cum să citești această carte Cartea este destinată în principal programatorilor cu experiență care lucrează cu Win API direct sau prin biblioteci de clasă Probabil că cel mai bine este ca un începător să înceapă cu o altă carte În primul rând, trebuie să vă familiarizați cu principiile structurii programelor Windows și să înțelegeți cu atenție cum funcționează acestea Dacă sunteți interesat doar de programarea grafică în sine și nu doriți să vă ocupați de detaliile implementării la nivel de sistem, citiți capitolele și , săriți peste capitolele și și continuați să citiți din capitolul Puteți chiar sări peste unele secțiuni ale capitolelor și , dacă doriți Începând cu capitolul , materialul este prezentat în mod consecvent și sistematic Dacă sunteți un programator experimentat și calificat, atunci știți exact de ce aveți nevoie Poate ar trebui să răsfoiți începutul cărții și să treceți direct la capitolul Dacă sunteți interesat de programarea la nivel de sistem (de exemplu, urmărirea apelurilor API), citiți părțile relevante din capitolele și , precum și capitolele și În cele din urmă, dacă nu sunteți deloc programator (de exemplu, dacă munca dvs este testarea software-ului), Capitolul vă oferă o prezentare generală a sistemului grafic Windows Probabil că merită să citiți începutul capitolului - veți afla tot ce trebuie să știți despre scurgerile de resurse GDI și veți avea la dispoziție câteva instrumente de diagnosticare utile Introducere Ce este pe CD Cartea vine cu un CD care conține multe exemple de programe, funcții și clase Mai exact, discul conține peste KB de cod sursă C++, KB de fișiere antet C++ și o versiune ușor modificată a fișierelor sursă pentru o bibliotecă bazată pe codul sursă gratuit al Independent JPEG Group (www ijg org ) Programele sunt compilate în de fișiere executabile, trei drivere în modul kernel și o bibliotecă de link dinamic în modul utilizator Desigur, doar o parte din codul programului este dată în carte CD-ul conține codul sursă complet, fișiere de spațiu de lucru Microsoft Visual C++, binare precompilate (versiuni de depanare și finale) și fișiere JPEG pentru capitolele despre algoritmul grafic CD-ul include un program de instalare cu rulare automată care instalează fișierele de program, creează legături adecvate de meniu și include adrese web importante de unde puteți descărca utilitare Microsoft și puteți găsi informații tehnice Programele au fost dezvoltate și testate în versiunea finală a Windows (build ) pe un adaptor video care acceptă accelerarea hardware grafică DirectX D și D, deși multe programe rulează cu succes pe Windows / /NT și nu necesită suport DirectX Pentru a compila programe pe cont propriu, următoarele componente trebuie să fie instalate pe sistemul dumneavoastră Despre Visual C++ Compiler O actualizare Visual Studio Service Pack (msdn microsoft com/vstudio/sp/vs sp ) Despre MSDN Library Books Online Un antet și fișiere de bibliotecă și utilitare actualizate din Platform SDK (www microsoft com/downloads/sdks/platform/platform asp) Asigurați-vă că compilatorul VC este configurat să utilizeze fișierele antet și directoarele bibliotecii ale Platform SDK A Fișierele de simboluri de depanare Windows sunt utilizate de unele utilitare și sunt de mare ajutor în depanare (www microsoft com/windows /downloads/otherdownloads/symbols) Despre Windows DDK (www microsoft com/ddk) este folosit de unele drivere în modul kernel Adăugați directorul inc DDK la directoarele antet VB Adăugați directorul Iibfre\i DDK în directoarele de fișiere ale bibliotecii VC Despre WinDebug (www microsoft com/ddk/debugging) este folosit de Utilitarele de sistem din Capitolul Deși toate exemplele din această carte sunt scrise în C++ fără a utiliza MFC, MFC, ATL sau OWL, programatorii pot folosi cu ușurință acest cod Chiar și programatorii Visual Basic sau Delphi vor găsi exemplele utile, deoarece aceste medii de dezvoltare acceptă apeluri directe ale funcției Win API De la editor Ce urmeaza? Când lucrează la o carte, autorul trebuie să-și organizeze gândurile, să efectueze cercetările necesare și să prezinte materialul într-o manieră logică, consecventă Sper că această carte, în care am încercat să transmit în detaliu cunoștințele dobândite, să îi poată învăța ceva pe colegii mei programatori Dar acum cititorii din întreaga lume devin profesorii și colegii mei practicanți Dacă găsiți vreo eroare sau inexactitate, dacă aveți comentarii, sugestii sau reclamații, vă rugăm să mă contactați prin intermediul site-ului meu personal http://www fengyuan com Acest site conține și răspunsuri la întrebări frecvente, actualizări, descrieri ale celor mai complexe exemple etc De la editor Trimiteți comentariile, sugestiile, întrebările dvs la comp@piter com (editura Peter, ediție computer) Ne-am bucura sa primim vesti de la tine! Pentru mai multe informații despre cărțile noastre, vă rugăm să vizitați site-ul web al editurii http://www piter com Capitolul Principii și concepte de bază Facem o călătorie prin sistemul grafic Windows și îl explorăm în sus și în jos, de la suprafața netedă (stratul de caracteristici grafice API Win ) până la fundul stâncos (stratul de ecran/driver de imprimantă) Sistemul grafic Windows conține multe elemente importante, dar accentul nostru se va concentra pe componentele sale principale: interfața Win GDI (Graphics Device Interface) și componenta DirectDraw a interfeței DirectX Funcțiile Win GDI API sunt implementate pe multe platforme, inclusiv Win s, Win / , Win NT / , Windows și WinCE, cu diferențe semnificative între aceste implementări De exemplu, Win s și Win / se bazează pe vechea implementare pe biți a GDI cu multe limitări, în timp ce implementările complete pe de biți ale Windows NT / și Windows sunt mult mai capabile Interfețele DirectDraw sunt specifice platformelor Win / , Win NT și Windows Această carte se concentrează în primul rând pe platformele Windows NT și Windows , care au cele mai puternice implementări ale acestor interfețe Note legate de alte platforme vor fi furnizate după cum este necesar Dar înainte de a ne aprofunda în sistemul grafic Windows, trebuie să înțelegem câteva concepte de bază care sunt foarte importante pentru cercetări ulterioare Acest capitol descrie elementele fundamentale ale programării C/C++ pentru Windows, oferă o scurtă prezentare generală a programării în limbaj de asamblare, a mediilor de programare și a instrumentelor de depanare și discută formatul fișierului executabil Win și arhitectura generală a sistemului de operare Windows Elementele fundamentale ale programării Windows în C/C++ NOTĂ - Se presupune că cititorul are deja ceva experiență de programare Windows, așa că materialul este prezentat foarte pe scurt Elementele fundamentale ale programării Windows în C/C++ Profesia de programator a trecut printr-o dezvoltare dramatică de la codurile de mașină „medievale” la limbaje de programare moderne, cum ar fi C, Visual Basic, Pascal, C++, Delphi și Java Se crede că numărul de linii de cod scrise de un programator pe zi este practic independent de limbajul folosit Prin urmare, cu cât limbajul se mișcă mai sus în ceea ce privește nivelul de abstractizare, cu atât munca programatorului devine mai productivă Până de curând, C era considerat cel mai comun limbaj de programare pentru Windows, așa cum puteți vedea cu ușurință din exemplele de programe incluse în Microsoft Platform Software Development Kit (Platform SDK) și Device Driver Kit (DDK) Limbile orientate pe obiecte, cum ar fi C++, Delphi și Java, câștigă rapid avânt și înlocuiesc treptat C și Pascal Ele alcătuiesc o nouă generație de limbaje de programare pentru Windows Fără îndoială, limbajele orientate pe obiecte sunt un pas înainte față de predecesorii lor De exemplu, C++, chiar și fără utilizarea unor facilități de obiecte „pure” (clase, moștenire, funcții virtuale etc ), depășește C în caracteristici moderne precum prototiparea rigidă, șabloane și funcțiile inline (inline) Cu toate acestea, scrierea de programe orientate pe obiecte pentru Windows nu este o sarcină ușoară, deoarece interfața aplicației Windows (Windows API) nu a fost concepută pentru a suporta limbaje orientate pe obiecte De exemplu, funcțiile de apelare indirectă (în special, gestionarea mesajelor și procedurile casetei de dialog) trebuie să fie globale Compilatorul C++ nu vă permite să treceți o funcție de clasă obișnuită ca funcție de apel indirect Pentru a „împacheta” API-ul Windows într-o ierarhie de clase, a fost dezvoltată biblioteca Microsoft Foundation Classes (MFC), care a devenit de fapt standardul pentru programarea orientată pe obiecte pentru Windows MFC rezolvă în mare măsură problema integrării limbajului orientat pe obiecte C++ cu API-ul Win orientat spre C MFC trece o singură funcție globală ca handler general de mesaje al ferestrei Această funcție convertește HWND într-un pointer la un obiect CWnd, trecând astfel de la un handle de fereastră Win la un pointer la un obiect fereastră C++ Odată cu creșterea popularității tehnologiilor OLE, COM și ActiveX, chiar și Microsoft a devenit îngrijorat de dimensiunea și complexitatea MFC, așa că acum este recomandat să utilizați Active Template Library (ATL), o altă bibliotecă de clasă de la Microsoft, pentru scrieți servere COM ușoare și controale ActiveX Capitolul Principii și concepte de bază În conformitate cu trecerea către programarea orientată pe obiecte, exemplele de cod din această carte sunt scrise în primul rând în C++, mai degrabă decât în C Pentru ca codul prezentat să beneficieze programatorii care lucrează în C, C++, MFC, ATL, C++ Builder și chiar Delphi cu Visual Basic, nici caracteristicile exotice ale C++, nici caracteristicile specifice MFC/ATL nu sunt folosite în carte Hello World Versiunea : Lansarea browserului Destul de teorie - să trecem la scrierea unor programe Windows simple în C ++ Mai jos este codul sursă pentru primul nostru program //Hei ol cpp #define STRICT #include #include #include const TCHAR szOperation[] = T(" Pen"^ const TCHAR szAddress[] = T("www helloworld com"): int WINAPI WinMain(HINSTANCE hlnst, HINSTANCE LPSTR IpCmd int nShow) { HINSTANCE hRslt = ShellExecute(NULL szOperatlon szAdresa NUL, NUL SW SHOWNORMAL); assert( hRslt > (INSTANCE) HINSTANCEJRROR) : returnează : } NOTĂ - - Exemplele de programe de pe CD-ul inclus sunt localizate în directoare numite în funcție de numerele capitolelor—ChaptOl, Chapt și așa mai departe Tot codul obișnuit este localizat într-un director include suplimentar la același nivel cu directoarele capitolelor Directorul fiecărui capitol conține un fișier de spațiu de lucru Microsoft Visual C++ care conține toate proiectele capitolului Fiecare proiect se află într-un subdirector separat; de exemplu, proiectul Hello se află în directorul Chapt \Hellol Referințele la fișiere partajate (de exemplu, win h) în textul sursă folosesc căi relative precum \\ \include\win h Acesta nu este programul standard „Hello, World”, limitat la emiterea unui mesaj text, ci un nou membru al acestei familii din era Internetului Dacă acest program este executat, funcția Win API Shell Execute va lansa browserul și va deschide pagina web specificată în acesta Există câteva lucruri de remarcat în acest program simplu, care sunt rareori văzute în exemplele banale date în alte cărți Autorul a inclus aceste aspecte în el, deoarece contribuie la dezvoltarea stilului corect de programare Programul începe cu definirea macro-ului STRICT Acest lucru se face astfel încât, atunci când includeți fișiere antet Windows, diferite tipuri de obiecte Elementele fundamentale ale programării Windows în C/C++ au fost interpretate diferit și a fost mai ușor pentru compilator să emită avertismente programatorului că confunda HANDLE cu HINSTANCE sau HPEN cu HBRUSH Când cititorii se plâng că unele exemple de cărți nici măcar nu se compila, sunt șanse ca acele exemple să nu fi fost testate cu definiția macro STRICT Acest lucru se datorează faptului că versiunile mai noi ale fișierelor antet Windows includ STRICT în mod implicit, în timp ce versiunile mai vechi nu Includerea fișierului oferă posibilitatea de a compila o singură sursă în binar cu sau fără suport Unicode Programele destinate sistemelor de operare din familia Windows / nu sunt recomandate a fi compilate în modul Unicode, iar dacă se face acest lucru, programatorul trebuie să fie foarte atent și să evite utilizarea funcțiilor API bazate pe Unicode care nu sunt implementate în Win / Rețineți că parametrul IpCmd al funcției WinMain nu este niciodată codificat în Unicode; pentru a obține versiunea TCHAR a liniei de comandă completă, utilizați funcția GetCommandLineO Includerea fișierului este în domeniul programării protejate Este de dorit ca programatorul să treacă prin fiecare linie a programului său și să se asigure că nu există erori Verificarea parametrilor și a valorilor returnate ale funcțiilor cu directiva assert ajută la detectarea situațiilor neașteptate pe parcursul fazei de dezvoltare Există o altă modalitate de a detecta erorile de programare - gestionarea excepțiilor în program Cele două definiții ale matricei TCHAR const asigură că aceste constante de șir sunt plasate în zona de date numai pentru citire a binarului final generat de compilator și linker Dacă includeți linii din formularul TC'print") direct într-un apel Shell Execute, cel mai probabil acestea vor ajunge într-o zonă de date de citire/scriere Plasarea constantelor într-o zonă de date numai pentru citire asigură că aceste date vor fi doar citite , iar dacă încercați să le scrieți, va apărea o eroare de protecție generală (GPF) În plus, aceste date pot fi partajate între diferite instanțe ale programului, ceea ce economisește memorie atunci când rulați mai multe instanțe ale aceluiași modul în sistem Numele celui de-al doilea parametru al funcției WinMain (denumit de obicei hPrevInstance) nu este specificat în apel deoarece nu este utilizat în programele Win În Winl , parametrul hPrevInstance conținea un handle pentru instanța anterioară a programului curent În Win , fiecare program rulează într-un spațiu de adrese separat Chiar dacă există mai multe instanțe ale aceluiași program care rulează pe sistem, de obicei nu se „văd” unul pe celălalt Scrierea unui program perfect este dificilă, dacă nu imposibilă, dar cu câteva trucuri poți face ca compilatorul să construiască binarul perfect Pentru a face acest lucru, trebuie să alegeți tipul potrivit de procesor, biblioteca de rulare, tipul de optimizare, metoda de aliniere a câmpului de structură și adresa de bază a DLL Informațiile de depanare, un fișier cu nume simbolice sau chiar o listă în limbaj de asamblare vă vor ajuta în procesul de depanare, de analizare a rapoartelor sau de reglare fină a performanței O altă abordare este analiza codului binar folosind date simbolice, instrumente de procesare rapidă Capitolul Principii și concepte de bază vezi Windows / /NT Explorer și Dumpbin; trebuie să vă asigurați că programul exportă funcțiile dorite, că nu importă nicio funcție neobișnuită și că binarul nu conține fragmente neașteptate De exemplu, un program care importă funcția a lui oleauto dll nu va funcționa în versiunile anterioare ale Win Dacă un program încarcă mai multe DLL-uri la aceeași adresă de bază, execuția sa va încetini din cauza relocării dinamice Dacă compilați proiectul Hellol cu opțiunile implicite, dimensiunea binarului executabil în versiunea de lansare este de KB Programul importă trei duzini de funcții API Win , deși în codul sursă este utilizată o singură funcție Există aproximativ de octeți de date globale inițializate implicați în program, deși nu sunt utilizate date direct în program Dacă încercăm să parcurgem programul, aflăm curând că WinMain nu este cu adevărat punctul de plecare al programului nostru Apelul către WinMain în funcția inițială WinMainCRTStartup reală este precedat de multe alte evenimente În programe la fel de simple precum Hellol cpp, puteți utiliza versiunea DLL a bibliotecii C runtime și puteți scrie propria implementare a funcției WinMainCRTStartup, caz în care compilatorul și linkerul vor genera cod binar foarte mic Această capacitate este demonstrată în exemplul următor Hello World Versiunea : Afișează text pe desktop Deoarece această carte este despre programarea grafică Windows, accentul principal al acestei cărți ar trebui să fie pe funcțiile grafice API Pe baza acestui fapt, următoarea versiune a „Hello, World” funcționează puțin diferit #define STRICT #define WIN LEAN AND MEAN # nclude #include #include void CenterText(HDC hDC, int x, int y LPCTSTR szFace LPCTSTR szMessage, punct int) HFONT hFont = CreateFont( -point * GetDeviceCaps(hDC LOGPIXELSY) / , , FW BOLD, TRUE, FALSE FALS ANSI-CHARSET, OUT TT PRECIS CLIP DEFAULT PRECIS PROOF-QALITY, VARIABLE PITCH, szFace): assert(hFont): HGDIOBJ hold = SelectObject(hDC hFont): SetTextAlign(hDC TA CENTER | TA BASELINE): Elementele fundamentale ale programării Windows în C/C++ SetBkMode(hDC TRANSPARENT): SetTextColor(hDC, RGB( , OxFF)): TextOut(hDC, x, y, szMessage tcslen(szMessage)): SelectObject(hDC, Hold): DeleteObject(hFont): const TCHAR szMessageLJ = T("Bună, lume"); const TCHAR szFace[] = T("Times New Roman"): Ipragma commentdinker, "-merge: rdata= text") #pragma commentdinker, "-align: ") extern „C” void WinMainCRTStartup() { HDC hDC = GetDC(NULL): afirm (hDC): CenterText(hDC, GetSystemMetrics(SM CXSCREEN) / GetSystemMetrics(SM CYSCREEN) / szFace, szMessage ): ReleaseDC(NULL hDC): ExltProcess(O): } Programul de mai sus folosește funcții GDI simple pentru a afișa șirul „Hello, World” în centrul ecranului fără a crea o fereastră Programul primește contextul dispozitivului pentru fereastra desktop (sau monitorul principal dacă există mai multe monitoare), creează un font italic de inch și afișează șirul „Hello, World” în modul transparent, în albastru solid Pentru a menține codul binar cât mai mic posibil, programul își creează propria funcție WinMainCRTStartup în loc să folosească implementarea standard furnizată de biblioteca de rulare C/C++ Ultima comandă din program, ExitProcess, încheie procesul De asemenea, programul îi spune linkerului să îmbine zona de date numai pentru citire ( rdata) cu zona de cod care poate fi citită ( text) Fișierul executabil generat în versiunea finală are o dimensiune de numai de octeți Hello World Versiunea : Crearea unei ferestre pe ecran complet Prima și a doua versiune a „Hello, World” nu erau programe Windows obișnuite care rulau într-o fereastră Au folosit doar câteva apeluri de funcții API Windows care au arătat cum să scrieți un program Windows rudimentar Un program tipic de ferestre scris în C/C++ înregistrează mai întâi mai multe clase de ferestre, apoi creează o fereastră principală (posibil mai multe Capitolul Principii și concepte de bază la ferestrele secundare) și intră într-o buclă în care toate mesajele primite sunt direcționate către gestionanții corespunzători Probabil, mulți cititori sunt bine familiarizați cu exemple similare ale celor mai simple programe Windows Pentru a nu crea un alt duplicat, vom încerca să scriem un program simplu de fereastră orientat pe obiecte în C++ fără a folosi MFC Pentru a face acest lucru, avem nevoie de o clasă KWindow foarte simplă, care implementează operațiunile de bază de înregistrare a unei clase de ferestre, crearea unei ferestre și livrarea mesajelor ferestre Primele două probleme sunt ușor de rezolvat, dar a treia este mai dificilă Desigur, am dori să facem din funcția de gestionare a mesajelor o funcție virtuală a clasei KWindow, dar API-ul Win interzice utilizarea unor astfel de funcții ca funcție de fereastră Când se apelează funcții de clasă C++, se trece implicit acest pointer, iar schemele lor de transmitere a parametrilor pot diferi de cele utilizate de funcția fereastră O soluție comună este utilizarea unei funcții de fereastră statică care transmite cereri către funcția de clasă C++ corespunzătoare Pentru a face acest lucru, funcția fereastră statică trebuie să aibă un pointer către o instanță KWindow În exemplul nostru, această problemă este rezolvată prin trecerea unui pointer către instanța KWindow la apelarea CreateWindowEx și stocarea acestuia în structura de date asociată fiecărei ferestre NOTĂ - - Toate numele claselor C++ din această carte încep cu litera „K” în loc de prefixul tradițional „C” Acest lucru facilitează lucrul cu clase în programele care utilizează MFC, ATL sau alte biblioteci de clase Mai jos este fișierul antet al clasei KWindow // învinge h #pragma o dată clasa KWindow { virtual void OnDraw (HDC hDC) { } virtual void OnKeyDown(WPARAM wParam LPARAM Param) { } virtual LRESULT WndProc(HWND hWnd, UINT uMsg WPARAM wParam LPARAMIParam); static LRESULT CALLBACK W ndowProc(HWND hWnd, UINT uMsg WPARAM wParam LPARAM IParam): virtual void GetWndClassEx(WNDCLASSEX & wc): public: HWND m hWnd: Elementele fundamentale ale programării Windows în C/C++ KWIndow(vold) { m hWnd } = NULL; virtual -KWIndow(vold) { } virtual bool CreateEx(DWORD dwExStyle LPCTSTR IpszClass LPCTSTR IpszName DWORD dwStyle int X, int y, int nWldth int nHeight, HWND hParent HMENU hMeniu HINSTANCE hlnst): bool RegisterClass(LPCTSTR IpszClass HINSTANCE hlnst): virtual WPARAM MessageLoop(vold); BOOL ShowW ndow( nt nCmdShow) const return ::ShowW ndow(m hWnd nCmdShow); } BOOL UpdateWindow(void) const { return ::UpdateWindow(m hWnd): } Clasa KWindow conține o singură variabilă m hWnd, care stochează mânerul ferestrei Clasa conține un constructor, un destructor virtual, o funcție pentru crearea unei ferestre, precum și funcții pentru bucla de procesare a mesajelor, afișarea și actualizarea ferestrelor Funcțiile private ale clasei KWindow definesc structura WNDCLASSEX și procesează mesajele pentru fereastra dată Funcția statică WindowProc este creată conform cerințelor API-ului Win ; transmite mesaje către funcția virtuală WndProc Multe dintre funcțiile clasei sunt definite ca virtuale, astfel încât comportamentul lor poate fi schimbat în clasele care derivă din KWindow De exemplu, diferite clase vor avea diferite implementări OnDraw, iar implementarea lor GetWndClassEx va folosi meniuri și cursore diferite O directivă la îndemână pentru compilator Visual C++ (#pragma opse) vă ajută să evitați includerea de mai multe ori a aceluiași fișier antet Pentru a obține același efect, puteți defini o macrocomandă unică pentru fiecare fișier antet și puteți sări peste fișierul antet dacă macrocomanda este deja definită Mai jos este implementarea clasei KWindow // win cpp #def ne STRICT #def ne WIN LEAN AND MEAN # nclude # nclude # nclude Capitolul Principii și concepte de bază # includeți „Awin h” LRESULT KWindow::WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM IParam) { swltch(uMsg) { caz WM KEYDOWN: OnKeyDown(wParam, IParam): return ; caz WM PAINT: { PAINTSTRUCT ps: BeginPaint(m hWnd, &ps): OnDraw(ps hdc): EndPaint(m hWnd, &ps): } returnează : caz WM-DESTROY: PostQuitMessage(O): returnează : } returnează DefWindowProcIhWnd uMsg, wParam iParam); } LRESULT CALLBACK KWindow::WindowProc(HWND hWnd, UINT uMsg WPARAM wParam LPARAM IParam) { KWindow*pWindow: dacă ( uMsg="WMJCCREATE ) { assert( ! IsBadReadPtr((void *) IParam, sizeof(CREATESTRUCT)) ); MDICREATESTRUCT*pMDIC" (MDICREATESTRUCT*) ((LPCREATESTRUCT) Param)-> pCreateParams; pWindow » (KWindow *) (pMDIC->lParam): assert( ! IsBadReadPtr(pWindow, sizeof(KWindow)) ): SetWindowLong(hWnd, GWL USERDATA, (LONG) pWindow); } el se pWindow"(KWindow *)GetWindowLong(hWnd, GWLJJSERDATA); dacă (pWindow) return pWindow->WndProc(hWnd, uMsg, wParam, IParam): el se returnează DefWindowProc(hWnd, uMsg, wParam, IParam): } bool KWindow::RegisterCTass(LPCTSTR IpszClass HINSTANCE hlnst) Elementele fundamentale ale programării Windows în C/C++ { WNDCLASSEXwc: dacă ( ! GetClassInfoEx(hInst IpszClass &wc) ) { GetWndClassEx(wc): wc hlnstance=hlnstance; wc lpszClassName = IpszClass; dacă ( !RegisterClassEx(&wc) ) returnează fals; } returnează adevărat; } bool KWindow;:CreateEx(DWORD dwExStyle LPCTSTR IpszClass LPCTSTR IpszName DWORD dwStyle int x int y, int nWidth int nHeight, HWND hParent HMENU hMeniu INSTANȚĂ (hlnst) { dacă ( ! RegisterClassdpszClass hlnst) ) returnează fals: // Folosiți MDICREATESTRUCT pentru a suporta ferestrele copil MDI MDICREATESTRUCT mdic: memset(& mdic, sizeof(mdic)); mdic Param = (LPARAM) aceasta; m hWnd = CreateWindowEx(dwExStyle IpszClass IpszName dwStyle, xy nWidth, nHeight hPărinte, hMeniu hlnst &mdic); returnează m hWnd!=NULL: } void KWindow::GetWndClassEx(WNDCLASSEX și wc) { memset(& wc, , sizeof(wc)); wc cbSize = sizeof(WNDCLASSEX); stil wc = ; wc IpfnWndProc și WindowProc; wc cbClsExtra = ; wc cbWndExtra » ; wc hlnstance - NULL: wc hlcon=NULL: wc hCursor = LoadCursor(NULL IDC ARROW); wc hbrBackground = (HBRUSH)GetStockObject(WHITE BRUSH); wc lpszMenuName = NULL: wc lpszClassName e NULL; wc hlconSm = NULL: Capitolul Principii și concepte de bază WPARAM KWindow::MessageLoop(void) { msg msg; while ( GetMessage(&msg, NULL, ) ) { TranslateMessage(&msg); D spatchMessage(&msg): } return msg wParam; } Implementarea KWindow este destul de simplă, cu excepția funcției statice WindowProc Funcția WindowProc este responsabilă pentru transmiterea mesajelor din sistemul de operare Windows către gestionatorii corespunzători ai clasei KWindow Pentru a face acest lucru, trebuie să putem obține un pointer către o instanță a clasei KWindow în funcția de fereastră Win Pe de altă parte, indicatorul este transmis doar atunci când se apelează CreateWindowEx Pentru ca o valoare transmisă o singură dată să fie reutilizată de mai multe ori, trebuie să o stocăm undeva MFC stochează informații într-o hartă globală care leagă valorile HWND la pointerii către instanțe ale clasei CWnd, astfel încât de fiecare dată când trebuie să fie livrat un mesaj, se face o căutare cu hash pentru instanța CWnd corectă În implementarea noastră simplă a clasei KWindow, a fost aleasă o soluție diferită - un pointer către instanța KWindow este stocat într-o structură de date menținută de sistemul de operare Windows pentru fiecare fereastră WindowProc obține în mod normal un pointer către KWindow în timpul procesării mesajului WM NCCREATE, care este de obicei trimis înaintea mesajului WM CREATE și conține aceeași valoare de pointer către o structură CREATESTRUCT Pointerul este stocat printr-un apel către SetWindowLong(GWLJJSERDATA) și mai târziu citit printr-un apel către GetWindowLong(GWLUSERDATA) Acesta este modul în care exemplul nostru simplu stabilește o conexiune între WindowProc și KWindow: :WndProc Operatorii tradiționali de gestionare a mesajelor (bazați pe C) au un dezavantaj semnificativ: necesită date globale atunci când au nevoie să acceseze date suplimentare Când creați mai multe instanțe ale unei ferestre care utilizează un handler de mesaje comun, acel handler de obicei nu funcționează Pentru ca diferitele instanțe de fereastră să utilizeze aceeași clasă comună de ferestre, fiecare instanță trebuie să aibă propria copie a datelor, care este accesată printr-un handler de mesaje comun Clasa KWindow rezolvă această problemă: creăm un handler de mesaje C++ care accesează datele instanței Funcția KWindow: :CreateEx nu trece acest pointer direct atunci când apelează funcția Win CreateWindowEx; în schimb, pointerul este trecut într-un câmp al structurii MDICREATESTRUCT Acest lucru este necesar pentru a suporta Multiple Document Interface (MDI) folosind aceeași clasă KWindow Pentru a crea o fereastră copil MDI, o aplicație trimite un mesaj WM MDICREATE către fereastra client MDI și îi transmite o structură MDICREATESTRUCT Fereastra client, implementată de sistemul de operare, este responsabilă pentru apelul final la funcția de creare a ferestrei CreateWindowEx De asemenea, rețineți că funcția CreateEx înregistrează clasa ferestrei și creează fereastra într-un singur apel Fiecare Elementele fundamentale ale programării Windows în C/C++ De fiecare dată când trebuie creată o fereastră, funcția verifică dacă clasa a fost înregistrată anterior și înregistrează clasa numai dacă este necesar După crearea clasei KWindow, nu mai trebuie să rezolvăm problemele de înregistrare a unei clase, crearea unei ferestre și organizarea unei bucle de mesaje din nou și din nou - este suficient să creăm o clasă care derivă din KWindow și să definim doar aspecte specifice în ea Mai jos este a treia versiune a programului „Hello, World”, un program C++ foarte obișnuit care rulează în modul ferestre // NeIIo srr #define STRICT #define WIN LEAN AND MEAN #include #include #include #include „ A \include\win h” const TCHAR szMessage[] = TANe^°- World!"); const TCHAR szFaceC] = T("Times New Roman"); const TCHAR szHintLJ = T("Apăsați ESC pentru a ieși "); const TCHAR szProgramC] = T("HelloWorld "); // Funcția CenterText este copiată din Hello cpp clasa KHelloWindow : public KWindow void OnKeyDown (WPARAM wParam, LPARAM IParam) if ( wParam==VK ESCAPE ) PostMessage(m hWnd WM CLOSE, ): } void OnDraw (HDC hDC) { TextOut(hDC, , , szHint, Istrlen(szHint)); CenterText(hDC, GetDeviceCaps(hDC, HORZRES)/ , GetDeviceCaps(hDC VERTRES)/ , szFace, szMessage, ): ) public: }: int WINAPI WinMain(HINSTANCE hlnst HINSTANCE, LPSTR IpCmd, int nShow) { KHelloWindow câștigă; win CreateEx( , szProgram, szProgram, WS POPUP , , Capitolul Principii și concepte de bază GetSystemMetrics( SM CXSCREEN ) GetSystemMetrics( SM CYSCREEN ), NULL, NULL hlnst): win ShowWindow(nShow): win UpdateWindow(): return win MessageLoop(); } În acest program, clasa KHeHoWindow este derivată din clasa KWindow Ea suprascrie funcția virtuală OnKeyDown pentru a gestiona tasta Esc și suprascrie funcția virtuală OnDraw pentru a gestiona mesajul WM PAINT Programul principal creează o instanță a clasei KHel oWorl d pe stivă, construiește o fereastră pe ecran complet, o afișează și intră în bucla normală de mesaje Unde este mesajul nostru „Bună, lume”? Funcția OnDraw îl desenează în timpul procesării mesajului WM PAINT Deci, am scris un program C++ pentru Windows în care nu există o singură variabilă globală Hello World Versiunea DirectDraw Output A doua și a treia versiune a „Hello, World” amintesc de vechile programe DOS care obișnuiau să captureze întregul ecran și să scrie date direct în memoria video Interfața DirectDraw, dezvoltată inițial de Microsoft pentru programarea grafică rapidă în jocuri, permite programelor să funcționeze la un nivel și mai scăzut, accesând memoria tampon de ecran și utilizând capabilitățile non-triviale ale adaptoarelor video moderne Mai jos este un program simplu în care ieșirea este realizată prin intermediul DirectDraw // He o srr #define STRICT #define WIN LEAN AND MEAN #include # nclude # nclude #include #include „" \ nclude\w n h" const TCHAR szMessage[] = T("Bună ziua, lume!"): const TCHAR szFace[] = T("Times New Roman"): const TCHAR szHintEJ = T ("Apăsați ESC pentru a ieși "): const TCHAR szProgram[] = T("Hei oWorld "): // Funcția CenterText este copiată din Hei o cpp clasa KDDrawWindow : public KWindow Elementele fundamentale ale programării Windows în C/C++ LPDIRECTDRAW Ipdd: LPDIRECTDRAWSURFACE Ipddsprimary: void OnKeyDown(WPARAM wParam LPARAM Param) { if ( wParam==VK ESCAPE ) PostMessage(m hWnd WM CLOSE ); } vold Blend( nt stânga Int dreapta int sus Int jos): vold OnDraw (HDC hDC) { TextOut(hDC szHint Istrlen(szHint)): CenterText(hDC GetSystemMetrics(SM CXSCREEN)/ GetSystemMetrics(SM CYSCREEN)/ szFace szMessage ): Amestecare ( ): } public: KDDrawWindow(void) { ipd - NULL: Ipddsprimary - NULL: ) -KDDrawWindow(void) { dacă ( Ipddsprimary ) { pddspri mary->Relea se(): Ipddsprimary - NULL: } dacă ( Ipdd ) { lpdd->Reiease(): Ipdd = NULL: } } bool CreateSurface(void): }: bool KDDrawWindow::CreateSurface(void) { HRESULT oră; hr = DirectDrawCreate(NULL &lpdd NULL): dacă (hr!=DD OK) returnează false: Capitolul Principii și concepte de bază hr = pdd->SetCooperativeLevel(m hWnd DDSCLJULLSCREEN | DDSCL EXCLUSIVE): dacă (hr!=DD OK) returnează fals; hr = lpdd->SetDisplayMode( ); dacă (hr!=DD OK) returnează fals; DDSURFACEDESC ddsd; memset(& ddsd sizeof(ddsd)); ddsd dwSize = sizeof(ddsd); ddsd dwFlags = DDSD CAPS; ddsd ddsCaps dwCaps = DDSCAPS PRIMARYSURFACE; returnează lpdd->CreateSurface(&ddsd, &lpddsprimary, NULL) ==DD OK: } void ini ine Blend(unsigned char *dest unsigned char *src) { dest[ ] = (dest[ ] + src[ ])/ ; destLl] = (destLU + src[l])/ ; dest[ ] = (dest[ ] + src[ ])/ ; } void KDDrawWindow:;Blend (int stânga, int dreapta int sus int jos) { DDSURFACEDESC ddsd; memset(&ddsd sizeof(ddsd)); ddsd dwSize = sizeof(ddsd); HRESULT hr = lpddsprimary->Lock(NULL &ddsd, DDLOCK SURFACEMEMORYPTR | DDLOCK WAIT NULL); assert(hr==DD OK); unsigned char *screen = (unsigned char *) ddsd lpSurface; pentru (int y=sus; y Unlosk(ddsd pSurface): } int WINAPI WinMain(HINSTANCE hlnst HINSTANCE LPSTR IpCmd int nShow) { Câștigă KDDrawWindow: win CreateEx(O, szProgram szProgram, WS POPUP , GetSystemMetrics( SM CXSCREEN ) GetSystemMetrics( SM CYSCREEN ) NUL NUL hlnst): win CreateSurfaceO: win ShowWindow(nShow); win UpdateWindow(): return win MessageLoop(): } Acest program simplu scrie direct în memoria tampon de ecran folosind DirectDraw Poate ați observat că am folosit din nou clasa KWindow fără a adăuga o singură linie de cod pentru a crea o fereastră, pentru a face gestionarea de bază a mesajelor și a organiza o buclă de mesaje Când lucrați cu DirectDraw, fiecare instanță a clasei KDDrawWindow derivată din KWindow trebuie să stocheze date suplimentare, și anume un pointer către un obiect DirectDraw și un pointer către un obiect DirectDrawSurface; ambii pointeri sunt inițializați când este apelată funcția CreateSurface Funcția CreateSurface comută ecranul la o rezoluție de x cu o adâncime de culoare de de biți per pixel și creează o suprafață DirectDraw primară Pointerii de interfață sunt eliberați atunci când este apelat destructorul Funcția OnDraw afișează un mic mesaj de ajutor în colțul din stânga sus și un mesaj mare albastru „Hello, World” în centrul ecranului; în ambele cazuri, ca în exemplul precedent, sunt utilizate apeluri normale de funcții GDI Cu toate acestea, există diferențe - după ce textul este afișat, este apelată noua funcție Bl end La începutul activității sale, funcția KDDrawWindow: :B captează memoria tampon de ecran în memorie și returnează un pointer care poate fi folosit pentru a lucra direct cu memoria ecranului Înainte de apariția DirectDraw, accesul direct la memoria tampon de ecran folosind funcțiile GDI (și chiar direct în GDI) nu era posibil, deoarece accesul era controlat de driverele dispozitivului grafic În exemplul nostru, folosim modul de biți/pixel, astfel încât fiecare pixel ocupă octeți de memorie Adresa unui pixel din memorie se calculează folosind următoarea formulă: pixel = (caracter nesemnat *) ddsd pSurface + y * ddsd lPitch + stânga * :s Capitolul Principii și concepte de bază Funcția scanează o zonă dreptunghiulară a ecranului de sus în jos și de la stânga la dreapta și caută pixeli în ea care nu sunt albi (fondul este vopsit în alb) Când este detectat un pixel care nu este alb, culoarea acestuia este neclară în raport cu vecinii săi situati în stânga, dreapta, sus și jos Ca urmare a estompării, unui pixel i se atribuie o valoare egală cu media aritmetică a valorilor a doi pixeli Pe fig arată rezultatul unei neclare netede a inscripției „Hello, World!” pe un fundal alb Orez Încețoșarea textului cu DirectDraw Dacă nu ați mai lucrat niciodată cu DirectDraw API, nu vă faceți griji Acest subiect este tratat în detaliu în Capitolul asamblator Tuturor ne place să urcăm – în sens social și chiar tehnic Reprezentanții profesiei noastre au trecut de mult de la programarea în coduri de mașină la C / Win API, C ++ / MFC, Java / AWT (Abstract Window Toolkit - clase pentru construirea unei interfețe grafice cu utilizatorul în Java) / JFC (Java Foundation Classes - a noua bibliotecă de clase de interfață cu utilizatorul, superioară AWT în ceea ce privește capacitățile sale), și doar câțiva indivizi nefericiți trebuie să creeze legături între limbaje abstracte și nivelul mașinii Progresul este un lucru bun, din păcate altceva Făcând următorul pas înainte, ne obișnuim rapid cu el ca singurul standard posibil și uităm tot ce s-a întâmplat înainte În zilele noastre, nimeni nu este surprins când cărțile Visual C++ se limitează la a descrie MFC, iar programatorii întreabă: „Cum pot face asta în MFC?” Cu fiecare nou nivel de abstractizare, apare un nou nivel intermediar de interacțiune între program și computer Implementarea noului nivel trebuie să se bazeze pe capacitățile nivelurilor inferioare - iar cel mai de jos nivel este în cele din urmă asamblatorul Chiar dacă nu aparține cercului restrâns al programatorilor de sisteme, o înțelegere profundă a limbajului de asamblare va oferi avantaje semnificative în munca ta profesională Cu ajutorul assemblerului, puteți depana programe și puteți înțelege cum funcționează sistemul de operare (imaginați-vă că aveți o excepție în kernel dll) Asamblatorul va ajuta la optimizarea programului și la obținerea performanțelor maxime din acesta Assembler vă oferă caracteristici de procesor care în mod normal nu sunt disponibile în limbi de nivel înalt, cum ar fi instrucțiunile procesorului legate de tehnologia Intel MMX (Multimedia Extensions) asamblator Această carte se va ocupa de asamblare pentru procesoare Intel Poate că, în edițiile viitoare, se va acorda atenție altor procesoare Pentru informații de bază despre procesoarele Intel, consultați Intel Architecture Software Developer's Manual, aflat pe pagina web a dezvoltatorului (developer intel com) Următoarele presupune că aveți cel puțin o înțelegere de bază a familiei de procesoare Intel și a limbajului de asamblare În general, se presupune că programele pe biți rulează în modul de adresare pe biți și că programele pe de biți rulează în modul de adresare pe de biți La procesoarele Intel, acest lucru nu este adevărat; ambele programe pe biți și pe de biți rulează în modul de adresare logică pe de biți Fiecare acces la memorie specifică o adresă de segment de biți și un offset de de biți Astfel, adresa logică este formată din de biți Procesoarele Intel funcționează în moduri pe și de biți În modul pe biți, lungimea maximă a segmentului este de KB, iar indicatorii de cod și date sunt implicit la un offset de biți În modul pe de biți, lungimea segmentului este limitată la GB, iar indicatorii de cod și date sunt implicit la un offset de de biți Cu toate acestea, lungimea de biți a unei instrucțiuni poate fi modificată folosind un prefix ( x pentru un operand, x pentru o adresă) Această tehnică vă permite să lucrați cu registre de de biți în modul de biți sau invers, să accesați registrele de biți în modul de de biți Modurile procesorului Intel nu trebuie confundate cu modulele EXE/DLL din lumea Windows Windows EXE/DLL poate conține o combinație de module pe și de biți Dacă sunteți pe Windows , aruncați o privire la fișierul dibeng dll - această bibliotecă pe biți conține segmente pe de biți pentru a oferi performanță pe de biți Diferențe între codul de biți și de biți există și în modul de adresare Programele pe biți folosesc de obicei un model de memorie segmentată, în care spațiul de adrese este împărțit în segmente Programele pe de biți sunt caracterizate prin adresare plată, în care întregul spațiu de adrese este tratat ca un segment de gigaocteți În procesele Win , segmentul de procesor înregistrează CS (segment de cod), DS (segment de date), SS (segment de stivă) și ES (segment suplimentar) la aceeași adresă virtuală Unul dintre avantajele adresei continue este că putem ușor generați o bucată de cod de mașină într-o matrice de date și apelați-o ca funcție Într-un program Winl , acesta ar trebui să mapați segmentul de date la segmentul de cod, folosind valoarea acestuia din urmă și offset-ul pentru a lucra cu codul din segmentul de date Deoarece toate cele patru registre de segmente principale se mapează la aceeași adresă virtuală , un program Win utilizează de obicei doar un offset de de biți ca adresă completă Cu toate acestea, la nivel de asamblare, un registru de segment poate fi combinat cu un offset pentru a forma o adresă de de biți De exemplu, registrul de segment FS, care este și registrul de segment de date pe procesoarele Intel, nu se mapează la adresa virtuală În schimb, se mapează la adresa de pornire a structurii de date a firului de execuție a programului (thread) suportată de sistemul de operare; prin această structură, funcțiile Win API funcționează cu informații importante la nivel de flux de program − Capitolul Principii și concepte de bază ultimul cod de eroare (funcțiile SetLastError/GetLastError), lanțul de gestionare a excepțiilor, datele locale de fir etc La nivel de asamblare, la apelarea funcțiilor API Win , se utilizează schema standard de trecere a parametrilor, adică parametrii sunt împinși în stivă de la dreapta la stânga Prin urmare, apelarea funcției fereastră din bucla de mesaje unsigned rslt = WindowProc(hWnd, uMsg wParam, Param); convertit în următorul fragment de asamblare: muta eax Param împinge eax mov eax, wParam împinge eax mută eax, umsg împinge eax mov eax, hWnd împinge eax caii WindowProc mov rslt eax Dintre capacitățile procesoarelor Intel Pentium care nu sunt disponibile la nivel C/C++, trebuie menționată o instrucțiune, care prezintă un interes deosebit pentru programatorii implicați în optimizarea programelor lor Aceasta este instrucțiunea RDTSC (Read Time Stamp Counter) Această instrucțiune returnează numărul de cicluri de când procesorul a fost pornit ca un întreg nesemnat pe de biți Numărul este returnat într-o pereche de registre de uz general EDX și EAX Aceasta înseamnă că pe un Pentium cu o frecvență de MHz, execuția programului poate fi măsurată cu o precizie de ns timp de ani Instrucțiunea RDTSC nu este suportată în prezent în Visual C++, nici măcar la nivel de asamblare inline, deși optimizatorul pare să înțeleagă că utilizarea acesteia modifică conținutul registrelor EDX și EAX Pentru a utiliza această instrucțiune, ar trebui să introduceți reprezentarea mașinii sale OxOF, x în program Mai jos este codul sursă pentru o clasă de cronometru care utilizează instrucțiunea RDTSC // Timer h #pragma o dată ini ine unsigned int GetCycleCount(void) { asm emit OxOF asm emit x } clasa KTimer { unsigned int m startcycle public: nesemnat int m overhead; asamblator KTImer(vold) { m overhead = ; startO; m overhead = StopO: } void Start(void) { m startcycle - GetCycl eCountO; } nesemnat nt Stop(void) ■ ( return GetCycleCount()-m startcycle-ni overhead; } }; Clasa KTimer stochează datele de sincronizare ca un număr de de biți, deoarece versiunea de de biți pe un computer de MHz este prea inexactă Funcția GetCycl eCount returnează numărul curent de cicluri ca număr nesemnat pe de biți Rezultatul generat de instrucțiunea RDTSC este conform formatului de valoare returnată de de biți al funcțiilor C Astfel, funcția GetCycl eCount este o singură instrucțiune de mașină Funcția Start citește numărul de bare la începutul intervalului; funcția Stop oprește cronometrarea și returnează diferența Pentru a îmbunătăți acuratețea măsurătorilor, este necesar să se țină cont de timpul petrecut pe funcțiile RDTSC Pentru a face acest lucru, constructorul clasei KTimer pornește și oprește cronometrul Valoarea rezultată este scăzută din rezultatele măsurătorilor ulterioare Exemplul de mai jos folosește clasa KTimer pentru a măsura numărul de căpușe și timpul necesar pentru a crea o perie uniformă // GDIspeed cpp #def ne STRICT #def ne WIN LEAN AND MEAN #include #include # nclude „ A A nclude\t mer h” int WINAPI W nMa n(HINSTANCE hlnst, HINSTANCE LPSTR IpCmd int nShow) { Cronometru KTimer; TCHAR mizerie[ ]; timer Start(); Dormi (looo): cpuspeedlO nesemnat = (nesemnat)(t mer Stop()/ ): timer Start(); cincizeci GlavakPrincipii și concepte de bază CreateSolidBrush(RGB(OxAA, OxAA, OxAA)); timp nesemnat - (nesemnat) timer Stop(): wsprintf(mess, T ("Viteza CPU $d $d mhz\n") T(„KTimer overhead fcd clock cycles\n”) T ("CreateSolidBrush fcd clock cycles fcd ns"), cpuspeedlO / , cpuspeedl % , (nesemnat) timer m overhead timp, timp * / cpusspeedlO): MessageBox(NULL dezordine, T(„Cât de rapid este GDI?”) MB OK): returnează : } Rezultatele măsurătorilor sunt afișate într-o casetă de mesaj (Fig ) Acum putem spune cu siguranță că crearea unei perii uniforme pe un computer cu un procesor Pentium MHz durează aproximativ de microsecunde Orez Cronometrare folosind instrucțiunea RDTSC pe procesoarele Intel Mediu de programare Există multe elemente esențiale pentru programarea eficientă în Microsoft Windows - computere, utilitare, cărți, documentație, tutoriale, informații de pe Internet și prieteni experimentați La prima vedere, această listă pare intimidantă, dar o mică parte din cele de mai sus este suficientă pentru a începe Restul va fi necesar pentru a programa sarcini mai complexe sau pentru a crește eficiența muncii tale În comparație cu vechile medii de programare pentru DOS sau versiuni de Windows pe biți, mediul Windows pe de biți este un mare pas înainte Dezvoltare și testare Un computer folosit astăzi pentru programare trebuie să îndeplinească următoarele cerințe minime: Pentium MHz cu MB de memorie, unitate CD-ROM, GB spațiu liber pe disc și o conexiune la rețea Mediu de programare Un procesor rapid accelerează munca compilatorului și a linkerului pentru a transforma sursa în cod binar (cu toate acestea, aceasta are o latură negativă - pierzi o scuză bună pentru a părăsi computerul și a bea cafea) Pentru a utiliza noile instrucțiuni (cum ar fi RDTSC), aveți nevoie de cel puțin un procesor Intel Pentium sau unul dintre modelele compatibile Procesor recomandat Pentium Pro, Celeron, Pentium III sau echivalent cu mai multe instrucțiuni, optimizări hardware și cache mai mare Dacă tu (sau șeful tău) îți poți permite, lucrează pe un computer cu două procesoare Acest lucru se va asigura că programul dvs nu va „încetini” pe computerele cu două procesoare - de exemplu, datorită faptului că fire diferite alocă memorie din același sistem heap (heap) Poate că cantitatea de RAM este un factor și mai important decât viteza procesorului Când rulați pe un computer cu sau MB de memorie, memoria sistemului va fi plină tot timpul, iar procesorul va trebui să petreacă cicluri de descărcare inactive și schimbând paginile active Ca urmare, viteza sistemului începe să depindă de viteza de acces la disc Pe măsură ce compilatoarele, SDK-urile (Software Development Kits) și DDK-urile (Device Driver Kits) cresc în dimensiune, spațiul liber pe disc începe să joace un rol important Instrumentele pentru dezvoltatori vin cu fișiere de ajutor mari, fișiere de antet și programe de exemplu Compilatorul cheltuiește mult spațiu construind fișiere antet precompilate, fișiere cu informații simbolice pentru depanare și baze de date pentru vizualizarea obiectelor Puteți accesa cu ușurință o pagină web și puteți descărca tot felul de utilități sau documentație de pe aceasta În plus, sistemul de operare aruncă conținutul RAM pe hard disk Este necesară o conexiune la rețea pentru a partaja și arhiva datele Depanatorul WinDbg la nivel de kernel necesită două computere conectate printr-un cablu serial sau de rețea Sistemele de control al versiunilor și de urmărire a defectelor funcționează de obicei printr-o rețea Aveți nevoie de două computere pentru a depana driverele la nivel de kernel în depanatorul WinDbg; programul depanat va rula pe unul, iar programul de depanare va rula pe celălalt Capitolul vă va arăta cum să utilizați WinDbg Debugger Extension DLL pe o singură mașină pentru a vizualiza structurile interne de date ale Windows NT/ GDI Vă recomandăm să instalați Windows NT sau Windows (în loc de Windows sau Windows ) pe computerul dvs de lucru Platformele Microsoft Windows NT și Windows ocupă din ce în ce mai încrezător o poziție de lider în rândul sistemelor de operare Din ce în ce mai multe cărți sunt publicate despre ele, iar setul de instrumente existent se extinde constant Pe lângă un computer (sau computere) care funcționează, veți avea nevoie de computere pentru testare (sau cel puțin acces temporar la acestea) Vă scrieți programele pentru utilizatorii Windows / /NT/ Prin urmare, trebuie să vă asigurați că acestea funcționează corect pe fiecare dintre aceste sisteme Programele pentru care viteza este importantă trebuie, de asemenea, testate Capitolul Principii și concepte de bază rulează în diferite configurații Se întâmplă ca, ca urmare a optimizării pe procesorul Pentium II, codul începe să ruleze de două ori mai repede, dar pe un Pentium în urmă cu trei ani, activitatea acestuia încetinește Compilatoare Un computer care funcționează nu este totul Veți avea nevoie și de un compilator care convertește un program în limbaj de programare într-o reprezentare de mașină Cu toate acestea, compilatoarele moderne nu se limitează la această funcție Sunt medii de programare integrate care includ un editor care evidențiază automat construcții de sintaxă, fișiere antet, texte sursă de bibliotecă și fișiere binare, documentație de ajutor, un compilator, un linker, un depanator la nivel de sursă, vrăjitori (vrăjitori), componente și alte ajutoare Dacă programezi exclusiv la nivelul Win API, atunci ai la dispoziție mai multe opțiuni: Microsoft Visual C++, Borland C++, Delphi, Microsoft Visual Basic etc Dar dacă vrei să scrii programe folosind Windows NT/ DDK, există nu este prea multă alegere - veți avea nevoie de compilatorul Microsoft Visual C++ În prezent, există mai multe versiuni ale compilatorului Microsoft Visual C++ De obicei, cea mai recentă versiune a compilatorului cu cea mai recentă versiune a Service Rask este instalată pe computerul de lucru - implementează noi caracteristici și îmbunătățiri, precum și remediază erorile găsite (cu toate acestea, actualizarea este uneori întârziată din cauza posibilelor probleme de compatibilitate) Exemplele de programe din această carte au fost compilate folosind Microsoft Visual C++ versiunea Dacă alegeți să utilizați o versiune anterioară, este posibil să primiți avertismente atunci când încărcați fișiere și proiecte din spațiul de lucru Alături de sistemul de operare și compilator, veți avea nevoie și de câteva instrumente de ajutor care sunt de obicei menționate doar atunci când este necesar Informațiile de depanare simbolică Windows NT/ vă ajută să înțelegeți cum funcționează sistemul și cum vă poate ajuta să detectați erori care apar numai în codul de sistem În cele din urmă, poate fi pur și simplu interesant să știm ce nume simbolice sunt folosite în sursele Microsoft Directorul \vc \vc \debug de pe CD-ul VC conține fișiere simbolice pentru unele DLL-uri importante de sistem, cum ar fi gdi dll, user dll etc Un set complet de fișiere simbolice de depanare este inclus pe CD-ul Windows NT/ în directorul \support\debug În versiunile mai noi de Windows , fișierele cu informații simbolice au crescut atât de mari încât Microsoft a trebuit să le pună pe un CD cu instrumente separat Când instalați fișiere simbolice, ar trebui să verificați tipul procesorului (І sau alpha), tipul și numărul versiunii Ele trebuie să se potrivească exact cu parametrii sistemului de operare pe care depanați Prezența informațiilor simbolice pentru modulele de sistem este un motiv suficient de bun pentru a porta dezvoltarea de la Mediu de programare Windows / pe Windows NT/ După aceea, veți putea folosi mai des comanda din meniul contextual Go To Disassembly în depanatorul Visual C++ și nu veți regreta De exemplu, puteți seta un punct de întrerupere când apelați Create-Sol idBrush și intrați în modul de asamblare În loc de o adresă hexazecimală imposibil de citit, depanatorul Visual C++ va afișa numele simbolic CreateSolid-Brush@ Devine clar că funcția primește octeți de parametri, sau doar o valoare de de biți Câteva linii mai jos este apelul către CreateBrush@ ; la apelarea acestei funcții, sunt trecuți parametri Astfel, GDI combină apelurile către funcții API specializate în apeluri mai generale Urmărind lanțul de apeluri, ajungem la funcția NtGdi Create-Sol dBrush@ , care provoacă întrerupere software x E Dacă doriți să introduceți un handler de întrerupere, depanatorul Visual C++ nu vă va lăsa Deci, pentru a crea o perie uniformă, GDI se referă la codul win k sys care rulează în modul kernel Nu trebuie să fii un expert în limbajul de asamblare pentru a-ți da seama ce se întâmplă - depanarea numelor simbolice sunt ca semnele rutiere pe care le urmezi pe parcurs Pe fig Figura prezintă un exemplu de utilizare a fișierelor cu simboluri de depanare în depanatorul Visual C++ \ I Crea t eSo i dBrush@ : Ф F xor c, ea x F ret LNtGdiCreateSolidBrush© : ea x eax fîd K dw ord ptr [esp* h] Creați eBrush© ( f f h) lx, Âh salut, [sp-H] uh KG+ GH Col' Q+- nr-l/Clh-i ee m>m Orez Utilizarea informațiilor simbolice în timpul depanării Compilatoarele Microsoft au două opțiuni pentru stocarea informațiilor de depanare În formatul vechi, este creat un fișier dbg pentru fiecare modul Noul format folosește două fișiere cu extensiile dbg și pdb Legătura către fișierul dbg este stocată în modul binar De exemplu, gdi dll se referă la fișierul dll\gdi dll din directorul de depanare corespunzător Din acest link, depanatorul încarcă fișierul $SystemRoot$\symbols\dll\gdi dbg Depanatorul nu este singurul instrument care poate lucra cu informații simbolice În plus, el însuși nu face nimic Descărcarea informațiilor de depanare și procesarea cererilor se realizează printr-o interfață specială Capitolul Principii și concepte de bază face (Image Help API) este o soluție modulară simplă Toate programele care folosesc această interfață vor putea obține aceleași informații Utilitarul dumpbin este un astfel de program, dar poate fi și propriul tău program Vizualizatorul de dependențe (depends exe) listează toate DLL-urile pe care modulul dumneavoastră le importă într-o formă recursivă convenabilă Acest lucru vă ajută să vă faceți o idee clară despre câte module sunt încărcate în timp ce programul rulează și câte funcții sunt importate Testați acest utilitar pe un program simplu MFC; vei fi uimit de câte funcții sunt importate fără știrea ta Acest utilitar poate fi folosit pentru a determina dacă un program va rula pe versiunea originală a Windows , care nu avea DLL-uri de sistem precum urlmon dll și exporta mai puține funcții în ole dll Microsoft Spy++ (spyxx exe) este un utilitar la îndemână și puternic pentru obținerea de informații despre Windows, mesaje, procese și fire de execuție a programelor Dacă, în timp ce programul rulează, doriți dintr-o dată să aflați în ce elemente constă o casetă de dialog standard (de tip File Open) sau de ce un mesaj pe care îl așteptați să nu fie trimis, încercați să utilizați utilitarul Microsoft Spy ++ Un utilitar WinDiff simplu și util (windiff exe) vă permite să comparați două versiuni ale unui fișier sursă sau conținutul a două directoare În plus, vă va ajuta să găsiți diferențele dintre versiunile originale și cele localizate ale fișierelor de resurse Micul program de text pstat exe afișează informații despre procesele, firele și modulele care rulează pe sistemul dumneavoastră Ieșirea sa listează toate procesele și firele de execuție, împreună cu timpul petrecut executând codul în modul utilizator și modul kernel, datele setului de lucru și un număr de erori de pagină La sfârșitul listei, pstat listează toate DLL-urile de sistem și driverele de dispozitiv încărcate în spațiul de adrese în modul kernel; fiecare modul are un nume, o adresă, un cod și dimensiunea datelor și un șir de versiune Rețineți că implementarea motorului win k sys GDI este încărcată la xaOOOOOOOO, driverul de ecran este încărcat la xfbef și așa mai departe Utilitarul Process Viewer (pview exe) afișează informații despre procese într-o formă grafică În special, arată câtă memorie este alocată pentru fiecare modul din proces Setul de instrumente Visual Studio include și alte programe utile: dumpbin exe pentru vizualizarea fișierelor PE, profile exe pentru o măsurare simplă a performanței, nmake exe pentru compilarea utilizând un shakefile și rebase exe pentru schimbarea adresei de bază a unui modul (în pentru a evita costul deplasării acestuia în memorie în timp ce programul rulează) Uneori va trebui să te uiți prin fișierele antet care la prima vedere par plictisitoare și neatractive Unii oameni cred că fișierele de antet nu sunt făcute pentru oameni, ci pentru compilatori Ei bine, chiar este Dar adevărul este că computerul este un instrument foarte precis și pedant Se supune implicit conținutului fișierelor antet și nu știe nimic despre ceea ce se spune în documentație sau în cărțile pentru programatori Se întâmplă ca documentația să conțină erori, iar apoi pentru final Mediu de programare Singurul răspuns este să vă referiți la fișierele antet Aruncă o privire la definiția TBBUTTON din documentația online Această structură este formată din câmpuri, nu? Dar dacă definiți o structură cu câmpuri, compilatorul va arunca o eroare Acum aruncați o privire la fișierul antet commctrl h - se dovedește că structura TBBUTTON conține un câmp suplimentar rezervat de doi octeți, adică este format din câmpuri Din fișierele antet, puteți vedea cum macrocomanda STRICT afectează compilarea, cum versiunile de funcții API cu și fără suport Unicode sunt mapate la funcțiile exportate, câte caracteristici noi au apărut în Windows și așa mai departe Dacă vă puteți ocupa de fișierele antet, atunci citirea textelor sursă va fi mult mai interesantă Citirea surselor bibliotecii C runtime este absolut esențială - acestea vă vor spune cum începe și se termină modulul și ce operațiuni sunt efectuate pe memorie în heap-ul de sistem atunci când sunt apelate malloc/free și new/delete În plus, veți afla de ce versiunea încorporată a memcpy este mai lentă decât apelarea funcției externe în unele situații Codul sursă MFC este destul de interesant de citit și de parcurs Partea de gestionare a mesajelor este deosebit de importantă deoarece combină C++ cu SDK-ul Win orientat spre C Codul sursă Active Template Library (ATL) este foarte diferit de codul sursă MFC Asigurați-vă că verificați clasa CWndProcThunk, care trece de la C la C++ cu câteva instrucțiuni ale mașinii Multe alte caracteristici utile sunt acceptate în Microsoft Visual Studio De exemplu, din meniul Fișier, puteți deschide o pagină HTML cu sintaxă codată în culori sau puteți deschide un fișier executabil pentru a vedea resursele acestuia Meniul Editare vă permite să căutați text în diferite moduri, precum și să setați puncte de întrerupere în anumite poziții din program, atunci când accesați date sau primiți mesaje Comenzile din meniul Proiect vă permit să generați o listă de programe de asamblare sau să atașați informații de depanare la versiunea finală a programului Folosind comenzile din meniul Debug, puteți solicita ca programul să fie terminat atunci când apar anumite excepții, precum și să vizualizați o listă de module încărcate Microsoft Platform SDK Microsoft Platform SDK (Software Development Kit) este un SDK pentru integrarea procesului de dezvoltare cu tehnologiile Microsoft existente și emergente Acest pachet este un succesor al SDK-ului Win și include SDK-ul BackOffice, SDK-ul ActiveX/Internet Client și SDK-ul DirectX Dar cel mai valoros lucru este că Microsoft Platform SDK este distribuit gratuit și este actualizat în mod regulat La momentul scrierii, Microsoft Platform SDK și alte SDK-uri sunt distribuite la: http://msdn microsoft com/downloads/sdks/platform/platform asp Deci, ce este inclus în SDK? Platform SDK conține o selecție uriașă de fișiere antet, biblioteci, documente electronice, utilități și exemple Capitolul Principii și concepte de bază programe Chiar dacă aveți deja compilatorul Microsoft Visual C++, instalarea celei mai recente versiuni a Platform SDK va fi totuși benefică De exemplu, dacă compilatorul dvs vine cu anteturi și biblioteci învechite, nu veți putea folosi noile caracteristici API introduse în Windows Problema este rezolvată prin încărcarea Platform SDK și conectarea noilor anteturi și biblioteci la compilator Se poate spune că Microsoft Visual Studio este un set integrat de instrumente pentru dezvoltarea programelor Win bazate pe compilatorul Microsoft Visual C++, în timp ce Platform SDK este o colecție cuprinzătoare de instrumente pentru dezvoltarea programelor Win folosind un compilator C/C++ extern În Microsoft Visual C++, compilatorul C++ cu bibliotecile de rulare C/C++, ATL și MFC ocupă locul central Platforma SDK nu include un compilator, fișiere antet pentru funcțiile C/C++ sau biblioteci de rulare Acest lucru permite companiilor independente să lucreze cu compilatoare alternative C/C++, fișiere antet și biblioteci, folosind un mediu de lucru diferit în locul soluțiilor Microsoft - și chiar programare în Pascal, dacă puteți traduce fișierele de antet API Windows în format Pascal Pentru a compila orice program din Platform SDK, trebuie mai întâi să instalați compilatorul și setul minim de biblioteci C runtime Platforma SDK include zeci de utilitare, dintre care unele sunt incluse și în Visual Studio Programul qgrep exe este conceput pentru a căuta text în modul linie de comandă (similar cu comanda Visual Studio Find in Files) Un monitor API destul de puternic (apimon exe) funcționează ca un depanator specializat Încarcă programul, interceptează apelurile de funcții API Windows, le înregistrează cu un marcaj de timp și urmărește parametrii și valorile returnate În situații neașteptate, monitorul API deschide o fereastră DOS în care puteți dezasambla programul, puteți vizualiza conținutul registrelor, setați puncte de întrerupere și puteți parcurge programul memsnap exe raportează utilizarea memoriei proceselor care rulează, cum ar fi dimensiunea setului de lucru și utilizarea memoriei nucleului Utilitarul pwalk exe afișează informații detaliate despre utilizarea memoriei virtuale de către un proces în spațiul de adrese al utilizatorului Programul arată modul în care spațiul de adrese utilizator este împărțit în sute de blocuri și raportează principalii parametri ai fiecărui bloc (starea, dimensiunea, secțiunea și numele modulului) Făcând dublu clic pe rândul listei, se afișează un dump hexazecimal al blocului corespunzător Programul sc (sc exe) oferă o interfață de linie de comandă managerului de control al serviciului Object Viewer extrem de util (winobj exe) vă permite să vizualizați toate obiectele active din sistemul dumneavoastră într-o vizualizare ierarhică ierarhică Aceste obiecte includ evenimente, mutexuri, canale, fișiere mapate în memorie, drivere de dispozitiv și așa mai departe De exemplu, în categoria dispozitivelor, există o linie PhysicalMemory - un driver de dispozitiv pentru lucrul cu memoria fizică Prin urmare, pentru a crea un mâner de bloc de memorie fizică, puteți utiliza o comandă ca: HANDLE hRAM = CreateFILE("\\\\ \\PhysicalMemory" ); Mediu de programare Dar cel mai interesant lucru despre Platform SDK este, desigur, colecția de exemple de programe (dacă nu ești intimidat citind programe Windows de modă veche scrise în C) În exemple, nu veți găsi C++, MFC, ATL sau utilizarea intensă a funcțiilor de rulare C Chiar și exemplele COM și DirectX sunt scrise în C și folosesc tabele cu indicatori de funcții în loc de funcții virtuale C++ De asemenea, în această secțiune sunt incluse sursele pentru mai multe utilități SDK, inclusiv windiff și spy Pe măsură ce citiți aceste programe, rețineți că au fost scrise la începutul anilor , majoritatea fiind scrise pentru API-ul Winl În aceste exemple, există adesea locuri care pot fi criticate pentru stilul prost de programare - nivelul scăzut de modularitate al codului, abuzul de variabile globale, verificarea insuficientă a erorilor și un impact clar asupra API-ului Winl Cu toate acestea, sunt multe lucruri utile de învățat din aceste exemple În tabel enumeră câteva programe legate de subiectul cărții Tabelul Exemple de programe SDK ale platformei grafice Calea către program Scurtă descriere a programului \graphics\directx Doi megaocteți de exemple DirectX \graphics\gdi\complexscript Imprimați text complex în arabă, thailandeză și ebraică \graphics\gdi\fonts Demonstrație multilaterală a caracteristicilor fonturilor API \graphics\gdi\metafile Descărcați, afișați, editați și imprimați metafișiere îmbunătățite \graphics\gdi\printer Funcții de imprimare, linii, pixuri, pensule \graphics\gdi\setdisp Schimbați rezoluția ecranului în mod dinamic \graphics\gdi\showdib Gestionarea rasterelor independente de dispozitiv \graphics\gdi\textfx Aplicați efecte textului \graphics\gdi\wincap Screen saver, cârlige \graphics\gdi\winnt\plgblt Folosind funcția PlgBlt \graphics\gdi\winnt\wxform Demonstrarea transformărilor lumii Conversie \graphics\gdi\video\palmap Format de date video (DIB) \sdktools\aniedit Editor animat de indicator al mouse-ului \sdktools\fontedit Editor de fonturi Bitmap \sdktools\image\drwatson Programul DrWatson Demonstrează lucrul simbolic pe tabel, dezasamblarea, depanarea simplă, listarea proceselor, parcurgerea stivei, descărcarea prin blocare etc \sdktools\imageedit Editor simplu de bitmap \sdktools\winnt\walker Vizualizați spațiul de memorie virtuală a procesului Continuare Capitolul Principii și concepte de bază Tabelul Continuare Calea către program Scurtă descriere a programului \winbase\debug\deb \winbase\debug\wdbgexts \winbase\winnt\service Exemplu de depanare Win Exemplu de extensie de depanare Win Funcții API pentru lucrul cu servicii O da! Până acum, nu a fost menționat cel mai util instrument al Platform SDK - depanatorul cu ferestre multiple WinDbg care funcționează la nivel de sursă Spre deosebire de depanatorul Visual Studio încorporat, WinDbg poate funcționa pe Windows NT/ atunci când depanează atât programele utilizator, cât și codul care rulează în modul kernel Pentru a-l utiliza ca depanator în mod kernel, trebuie să conectați două computere cu un cablu serial sau de rețea În plus, WinDbg vă permite să vizualizați depozitele de blocare WinDbg este tratat mai detaliat în Capitolul Daca vorbim de utilitati, atentie la instrumentele profesionale Numega BoundsChecker verifică apelurile de funcții API pentru scurgeri de memorie și resurse Excelentul depanator SoftICE/W oferă atât depanare în modul utilizator, cât și în modul kernel, acceptă cod pe și de biți, toate pe aceeași mașină Vă permite să treceți prin codul din modul utilizator la codul din modul kernel și apoi înapoi Profilul TrueTime este conceput pentru a găsi secțiuni de cod care reduc performanța programului În cele din urmă, vTune și compilatorul Intel C++ sunt pentru cei care doresc să profite la maximum de programul lor și să profite de instrucțiunile avansate MMX și SIMD (Single Instruction Multiple Data) ale Intel Kit de dezvoltare a driverelor Microsoft SDK-urile Microsoft Visual C++ și Platforma sunt orientate spre scrierea unor programe comune la nivel de utilizator, cum ar fi WordPad sau chiar Microsoft Word Cu toate acestea, pentru funcționarea sistemului de operare (în special cu un număr mare de dispozitive - hard disk, adaptoare video, imprimante etc ) este nevoie de un alt tip de program - drivere de dispozitiv Driverele de dispozitiv sunt încărcate în spațiul de adrese kernel Alături de funcțiile Win API, structurile de date Win API devin indisponibile Ele sunt înlocuite cu apeluri la funcțiile sistemului kernel și la interfețele driverului de dispozitiv Pentru a scrie drivere de dispozitiv în Windows, aveți nevoie de pachetul Microsoft Driver Development Kit, distribuit gratuit de Microsoft (există DDK-uri pentru Windows / /NT / ): http://www w m i c moale com/dd la/ DDK, ca și Platform SDK, este o colecție imensă de fișiere antet și bibliotecă, documentație online, utilități și programe eșantion DDK include fișiere antet atât pentru funcțiile API Win , cât și pentru driverele de dispozitiv De exemplu, în fișierul wingdi h, Mediu de programare Funcțiile Win GDI API și, în fișierul winddi h, interfața dintre motorul GDI și driverele de ecran sau de imprimantă În exemplele DirectDraw, fișierul ddraw h documentează funcțiile DirectDraw API, iar fișierul ddrawint h definește interfața driverului Windows NT DirectDraw Fișierele bibliotecii sunt împărțite în funcție de tipul de asamblare în două categorii: gratuite (gratuite) și verificate (bifate) DDK include, de asemenea, biblioteci de import pentru DLL-urile sistemului kernel, cum ar fi win k lib pentru win k sys Directorul de ajutor conține specificații detaliate ale interfeței driverului de dispozitiv și ghiduri pentru dezvoltarea driverului Fără îndoială, directoarele cu textele sursă ale exemplelor au o valoare deosebită De exemplu, directorul \src\video\displays\s virge conține peste MB de surse de drivere s VirGE pentru suport pentru GDI, DirectDraw și grafică D NOTĂ - - Dezvoltarea driverelor de dispozitiv nu intră în domeniul de aplicare al acestei cărți – există deja câteva cărți bune pe piață despre dezvoltarea driverelor Dar aceste cărți se concentrează de obicei pe driverele de uz general, cum ar fi driverele I/O și driverele de sistem de fișiere Această carte aruncă o privire detaliată asupra programării grafice pe Windows Ne vom uita la modul în care motorul GDI implementează apelurile de funcții GDI/DirectDraw și, în cele din urmă, le transmite driverelor de dispozitiv Prin urmare, subiectul nostru include drivere de ecran (inclusiv suport DirectDraw), drivere de font și drivere de imprimantă În plus, driverele în modul kernel vă permit să ocoliți API-ul în modul utilizator și să faceți ceva ce nu este posibil cu API-ul Win Capitolul arată cum un driver simplu în mod kernel vă poate ajuta să înțelegeți cum funcționează motorul GDI Codul executabil din DDK, ca și în Platform SDK, este construit folosind un compilator extern C DDK include un utilitar de construire a proiectului (build exe) care simplifică procesul de construire a driverelor Construiește o întreagă ierarhie de cod sursă pentru diferite platforme Este probabil ca, cu sursele disponibile, build exe va putea construi un întreg sistem de operare în modul linie de comandă La construirea driverelor de dispozitiv, sunt utilizate opțiuni speciale de compilare și linker care nu sunt acceptate în Microsoft Visual C++ Astfel, cel mai convenabil este să construiți drivere de dispozitiv în modul linie de comandă DDK include și alte utilități Programul break exe, care rulează în modul linie de comandă, atașează un proces de depanare Expertul de configurare a depanatorului (dbgwiz) vă ajută să configurați WinDbg Utilitarul gflags vă permite să schimbați zeci de steaguri de sistem De exemplu, puteți activa modul de marcare a blocurilor de memorie alocate cu datele proprietarului pentru a detecta scurgerile de memorie Programul poolmon exe monitorizează alocarea/dealocarea memoriei kernelului Programul regdmp scoate conținutul registry într-un fișier text Rețeaua de dezvoltatori Microsoft Microsoft Developer Network (MSDN) este o arhivă imensă de informații de referință pentru programatorii Microsoft Windows MSDN conține câțiva gigaocteți de documentație, articole tehnice, programe exemple, articole de reviste, cărți, Capitolul Principii și concepte de bază specificațiile și, în general, tot ceea ce ați putea avea nevoie atunci când programați pentru Microsoft Windows, inclusiv documentația pentru Platform SDK, DDK, Visual C++, Visual Studio, Visual Basic, Visual J++ etc * MSDN conține aproape tot ceea ce (conform Microsoft) trebuie să știți când programați pentru Windows Versiunile mai noi ale Microsoft Visual Studio folosesc MSDN ca sistem de referință, care consumă mult spațiu pe disc În tabel Tabelul listează componentele MSDN legate de programarea grafică Windows Tabelul Componente de bază MSDN legate de programarea grafică Platform SDK\Servicii grafice și multimedia\Microsoft DirectX Platform SDK\Servicii grafice și multimedia\GDI Documentație DDK\Windows DDK\Drifere grafice Din când în când, veți vedea link-uri către materiale MSDN Dacă citiți această carte fără acces la MSDN, este o idee bună să imprimați conținutul secțiunilor enumerate Pe lângă cele trei blocuri mari de documentație SDK/DDK, MSDN conține o mulțime de informații utile despre programarea grafică Windows sub formă de articole tehnice, articole din baza de cunoștințe, specificații etc Când citiți aceste materiale, ar trebui să acordați atenție datei de scris și platforma pentru care sunt au fost scrise deoarece informațiile utile sunt intercalate cu vechituri învechite O listă parțială a articolelor este dată în tabel Tabelul Componente MSDN suplimentare legate de programarea grafică Specifications\Applications\True Type Font Specification Specificații\Platforms\Microsoft Portable Executable și Common Object Form Specification Specificații\Tehnologii și limbi\Standardul UniCode, versiunea Articole tehnice\Multimedia\Basele programării jocurilor DirectDraw Articole tehnice\Multimedia\Noțiuni introductive cu Direct D: un tur și ghid de resurse Articole tehnice\Multimedia\Texture Wrapping Simplificat Articole tehnice\Multimedia\GDI\* * (zeci de articole utile) Articole tehnice\Windows Platform\Memory\Give Me a Handle, iar D vă arată un obiect Articole tehnice\Windows Platform\Windows Management\Windows Classes în Win Backgrounders\Windows Platform\Base\The Foundations of Microsoft Windows NT System Architecture Format de fișier executabil Win Format de fișier executabil Win Probabil, mulți își vor aminti expresia „Algoritmi + structuri de date = Programe”, atribuită lui N Wirtch, părintele familiei de limbi Pascal, al cărei reprezentant modern este Delphi Cu toate acestea, binarul compilat în sine este o structură de date al cărei conținut este procesat de sistem atunci când programul este încărcat în memorie pentru execuție Pe platformele Win , această structură de date este denumită formatul „Pi-table Executable” sau, pe scurt, PE Cunoașterea formatului de fișier PE simplifică foarte mult programarea Windows Aceste cunoștințe fac posibilă înțelegerea modului în care codul sursă este convertit în cod binar, unde sunt stocate variabilele globale și cum sunt inițializate, cum funcționează variabilele partajate și așa mai departe Toate DLL-urile de pe un sistem Win sunt în format PE; prin urmare, cunoscând formatul PE, veți înțelege mai bine cum funcționează mecanismul de conectare dinamică, cum are loc rezoluția referințelor în timpul importului și cum să evitați modificarea dinamică a adresei de bază a unui DLL Metoda de interceptare a funcțiilor API se bazează în mare măsură pe cunoașterea structurii tabelului de funcții importate În cele din urmă, cunoașterea formatului PE vă permite să înțelegeți mai bine structura spațiului de memorie virtuală în mediul Win Există mai multe locuri în această carte în care cunoașterea formatului de fișier PE este utilă, așa că vom arunca o privire rapidă asupra formatului în sine și a formei sale odată încărcate în memorie Programatorii scriu codul sursă al programului în C, C++, asamblare sau alte limbaje Aceste surse sunt apoi traduse de compilator în fișiere obiect în format OBJ Fiecare fișier obiect conține variabile globale (fie inițializate, fie neinițializate), date imuabile, resurse, cod executabil în limbajul mașinii, nume simbolice pentru conectare și informații de depanare Fișierele obiect ale unui modul sunt legate de linker la biblioteci, care sunt ele însele o colecție de fișiere obiect Cele mai comune sunt bibliotecile de rulare C și C++, bibliotecile MFC/ATL, bibliotecile de import Win API sau funcțiile sistemului Windows kernel Linker-ul rezolvă toate legăturile reciproce dintre legăturile obiect și biblioteci De exemplu, dacă funcția de bibliotecă C++ new este apelată în programul dvs , linker-ul găsește adresa new în biblioteca de rulare C++ și o pune în program Linker-ul combină apoi toate variabilele globale inițializate într-o secțiune, toate variabilele globale neinițializate într-o altă secțiune, tot codul executabil într-o a treia secțiune și așa mai departe Gruparea diferitelor părți ale fișierelor obiect în secțiuni diferite se face din două motive: protecție și utilizarea optimă a resurselor Datele imuabile și codul executabil sunt de obicei declarate doar pentru citire Acest lucru ajută programatorul să găsească erori în program dacă sistemul de operare detectează o încercare de a scrie în zona de memorie corespunzătoare Setarea atributului de acces numai în citire se face de către linker Desigur, secțiuni de variabile globale (atât inițializate, cât și neinițializate) trebuie să fie disponibile atât pentru citire, cât și pentru scriere Codul sistemului de operare Windows folosește pe scară largă DLL-urile; Capitolul Principii și concepte de bază de exemplu, toate programele GUI Win necesită fișierul gdi dll Pentru o utilizare optimă a memoriei, secțiunea de cod executabil gdi dll este stocată în memorie o singură dată pe sistem Diferite procese funcționează cu codul DLL printr-un fișier mapat în memorie Acest lucru este posibil datorită faptului că codul executabil este doar pentru citire, ceea ce înseamnă că va fi același pentru toate procesele Datele globale nu pot fi partajate între procese decât dacă au fost marcate în mod special ca partajate Fiecare secțiune are asociat un nume simbolic, prin care poate fi referită în opțiunile de linker Codul sau datele aparținând aceleiași secțiuni au aceleași atribute Memoria pentru secțiuni este alocată pagină cu pagină, deci pe procesoarele Intel dimensiunea blocului minim de memorie alocat pentru o secțiune este de KB Unele secțiuni utilizate în mod obișnuit sunt enumerate în tabel Tabelul Secțiunile utilizate în mod obișnuit ale fișierelor PE Nume Atribute conținut text Cod executabil Cod, execuție, citire data Date globale inițializate Date inițiale, citire/scriere rsrc Resurse Date inițializate, numai pentru citire bss Date globale neinițializate Citire/Scriere rdata Date imuabile Date inițiale, numai pentru citire idata Director de import Date inițiale, citire/scriere edata Director de export Date inițiale, numai pentru citire reloc Tabel de configurare a adreselor Date inițiale, memorie care poate fi dezactivată, numai citire shared Date partajate Date inițiale, memorie partajată, citire/scriere Codul executabil și datele globale din fișierele PE nu sunt practic structurate - nimeni nu vrea să ajute hackerii să-și spargă programele Dar restul datelor sistemului de operare trebuie căutate din când în când De exemplu, la încărcarea unui modul, încărcătorul trebuie să caute în tabelul funcțiilor importate și să ajusteze valorile adresei; când utilizatorul apelează GetProcAddress, căutarea se face în tabelul de export - Format de fișier executabil Win funcții rubile În fișierele PE, tabele speciale numite directoare sunt rezervate în astfel de scopuri Cele mai frecvent utilizate directoare sunt importurile, importurile legate, importurile întârziate, exporturile, relocările, resursele și informațiile de depanare Combinăm secțiuni și directoare, adăugăm câteva antete cu informații de serviciu - și obținem un fișier PE (Fig ) IMAGE DOS HEADER DOS stub IMAGE NT HEADER Semnătura fișierului PE IMAGE FILE HEADER IMAGE OPTIONAL HEADER R Tabel de secțiuni IMAGE SECTION HEADER[] secțiune text (binară) secțiunea de date (date inițiale) Secțiunea geios (tabel de setare a adreselor) secțiunea rsrc (constant) rdata sectiunea (resurse) Orez Structura fișierelor portabile în format executabil Fișierul PE începe cu un antet de fișier DOS EXE (structură IMAGE DOS HEADER) deoarece Microsoft dorește ca programele Win să poată rula într-o sesiune DOS Imediat după IMAGE DOS HEADER este un stub, un mic program DOS care generează o întrerupere software pentru a imprima un mesaj de eroare și închide programul Stub-ul este urmat de antetul actual al fișierului PE (IMAGE NT HEADERS) Rețineți că lungimea programului stub nu este fixă, astfel încât valoarea câmpului e lfanew al structurii IMAGE DOS HEADER trebuie utilizată pentru a determina offset-ul structurii IMAGE NT HEADERS Structura IMAGE NT HEADERS începe cu o semnătură de octeți, care trebuie să fie egală cu IMAGE NT SIGNATURE Macro definită în winnt h - Notă transl Capitolul Principii și concepte de bază În caz contrar, poate fi un fișier OS/ sau VxD Structura IMAGE FILE HEADER conține ID-ul procesorului țintă, numărul de secțiuni din fișier, timpul de construire, un pointer către tabelul de simboluri și dimensiunea antetului „opțional” În ciuda numelui său, structura IMAGE OPTIONAL HEADER nu este opțională Apare în fiecare fișier PE deoarece informațiile pe care le conține sunt prea importante Această structură stochează adresa de bază recomandată a modulului, dimensiunile codului și datelor, adresele codului și bazei de date, configurația heap și stiva, cerințele pentru versiunea sistemului de operare și a subsistemului și un tabel de director Fișierul PE conține multe adrese pentru referințe la funcții, variabile, nume, tabele etc Unele dintre ele sunt stocate ca adrese virtuale care pot fi utilizate direct după ce modulul este încărcat în memorie Dacă modulul nu poate fi încărcat la adresa de bază recomandată, încărcătorul corectează datele conform adresei reale Cu toate acestea, majoritatea adreselor sunt relativ la începutul antetului fișierului PE Asemenea adrese sunt numite „adrese virtuale relative” (adrese virtuale relative, RVA) Rețineți că valoarea RVA nu se potrivește cu offset-ul din fișierul PE înainte de a fi încărcat în memorie Faptul este că secțiunile din fișierele PE sunt de obicei aliniate pe granițele de de biți, iar sistemul de operare utilizează alinierea paginilor Pentru procesoarele Intel, dimensiunea paginii este de de octeți Adresele RVA sunt calculate presupunând că secțiunile sunt aliniate la pagină - acest lucru reduce supraîncărcarea resurselor în timpul execuției programului Mai jos este o clasă C++ simplă pentru a efectua operații simple pe modulele Win încărcate în memorie Constructorul arată cum să obțineți pointeri către structurile IMAGE DOS HEADER și IMAGE NT HEADER Funcția GetDirectory demonstrează obținerea unui pointer către datele directorului Vom îmbunătăți această clasă astfel încât să aducă beneficii practice clasa KPEFIle const char * pModule: PIMAGE DOS HEADER pDOSHeader; PIMAGE NT HEADERS pNTHeader: public: const char * RVA Ptr(uns gned rva) { Dacă ( (pModule!=NULL) && rva) returnează pModule + rva: el se returnează NULL: } KPEF e(HMODULE hModule); volum const * GetDirectory(int id): PIMAGE IMPORT DESCRIPTOR GetImportDescriptor(LPCSTR pDllName): Format de fișier executabil Win const unslgned * GetFunctionPtr(PIMAGE IMPORT DESCRIPTOR plmport, LPCSTR pProcName); FARPROC SetImportAddress(LPCSTR pDllName, LPCSTR pProcName FARPROC pNewProc): FARPROC SetExportAddress(LPCSTR pProcName, FARTPROC pNewProc): }: KPEFile::KPEF le(HMODULE hModule) { pModule = (const char *) hModule: if ( IsBadReadPtr(pModule, sizeof(IMAGE DOS HEADER))) { pDOSHeader = NULL; pNTHeader = NULL: } el se { pDOSHeader = (PIMAGE DOS HEADER) pModul: if ( IsBadReadPtr(RVA Ptr(pD SHeader->e lfanew), sizeof(IMAGE NT HEADERS))) pNTHeader = NULL: el se pNTHeader = (PIMAGE NT HEADERS) RVA Ptr(pD SHeader-> e lfanew); } } // Funcția returnează adresa directorului PE const vold * KPEFile::GetDirectory(int id) { return RVA Ptr(pNTHeader->OptionalHeader DataDirectory[id], VirtualAddress); } Acum că avem o înțelegere conceptuală generală a formatului fișierului PE, să ne uităm la câteva exemple practice Director de import Când utilizați o funcție API Win (de exemplu, LoadLibraryW) într-un program, este generat un cod binar de următoarea formă: DWORD ітр LoadLibrary@ = x E C : cai dword ptr[ imp LoadLibraryW@ ] Atenție la un detaliu curios: compilatorul creează o variabilă globală internă și folosește un apel indirect în loc de unul direct Cu toate acestea, compilatorul are motive destul de bune pentru acest lucru Linker-ul nu știe adresa exactă a LoadLibraryW@ la momentul link-ului, deși poate face o ghicire bazată pe o singură versiune a kernel dll (specificată de Capitolul Principii și concepte de bază în directorul de import legat) Prin urmare, în majoritatea cazurilor, încărcătorul de module trebuie să găsească adresa corectă a funcției importate și să facă corecții la imaginea modulului încărcat Aceeași funcție (cum ar fi LoadLibraryW) poate fi apelată de mai multe ori într-un modul Din motive de performanță, încărcătorul ar prefera să patcheze în cât mai puține locuri posibil, ideal într-un singur loc pentru fiecare funcție importată Un astfel de loc este o variabilă care conține adresa funcției importate De obicei, unor astfel de variabile li se atribuie nume interne de forma ітр ххх Adresele funcțiilor importate sunt fie alocate de la secțiune separată (denumită de obicei idata) sau combinată cu text pentru a economisi spațiu Fiecare modul importă de obicei mai multe funcții din module diferite În fișierul PE, directorul de import se referă la o matrice de structuri IMAGE IMPORT DESCRIPTOR, fiecare corespunzând unui modul care urmează să fie importat Primul câmp al IMAGE IMPORT DESCRIPTOR conține offset-ul din tabelul indicii/nume, iar ultimul câmp conține offset-ul din tabelul cu adrese de import Cele două tabele au aceeași lungime și fiecărui element îi corespunde o funcție de import Intrarea în tabelul de adrese de import conține un număr de secvență dacă este setat bitul cel mai semnificativ (import după numărul de secvență) sau un decalaj de indiciu de biți urmat de numele funcției care urmează să fie importată (import după nume) Deci, tabelul indicii/nume poate fi folosit pentru a căuta directorul de export pentru modulul din care importăm În fișierul PE original, tabelul cu adrese de import poate conține aceleași informații ca și tabelul indicii/nume, adică decalajul indicii urmat de numele funcției În acest caz, încărcătorul găsește adresa funcției importate și modifică intrarea în tabelul adreselor importate Prin urmare, după ce fișierul PE este încărcat, tabelul de adrese importate se transformă de fapt într-un tabel de adrese ale funcțiilor importate De asemenea, linkerul poate lega modulul la unele DLL, astfel încât tabelul să fie inițializat cu adresele funcțiilor importate pentru o anumită versiune a DLL În acest din urmă caz, tabelul de adrese de import conține adresele funcțiilor de import asociate În ambele cazuri, tabelul de funcții importate conține variabile interne de forma ітр LoadLibrary@ Să încercăm să implementăm funcția KPEFile: :SetImportAddress Această funcție modifică adresa funcției importate în modul și returnează valoarea inițială a adresei // Funcția returnează valoarea câmpului PIMAGE IMPORT DESCRIPTOR // pentru modulul importat PIMAGE IMPORT DESCRIPTOR KPEFile;;GetImportDescriptor( LPCSTR pDllName) { // Obțineți IMAGE IMPORT DESCRIPTOR PIMAGE IMPORT DESCRIPTOR plmport = (PIMAGE IMPORT DESCRIPTOR) GetDirectory(IMAGE DIRECTORY ENTRY IMPORT); Dacă ( pImport==NULL ) Format de fișier executabil Win returnează NULL; whlle ( pImport->F rstThunk ) { if ( str cmp(pDlIName, RVA Ptr(pImport->Name))== ) return plmport; // Treceți la următorul modul de import plmport ++; } returnează NULL: } // Funcția returnează adresa variabilei tr xxx // pentru funcția importată const unsigned * KPEFile::GetFunctionPtr( PIMAGE IMPORT DESCRIPTOR plmport, LPCSTR pProcName) { PIMAGE THUNK DATA pThunk; pThunk = (PIMAGE THUNK DATA) RVA Ptr(pImport-> OriglnalFirstThunk); pentru (Int = : pThunk->ul Function; i++) { potrivire bool; // După numărul de serie Dacă ( pThunk->ul Ordinal & x ) se potrivește = (pThunk->ul Ordinal & OxFFFF) == ((DWORD)pProcName); altfel potrivire = str cmp(pProcName, RVA Ptr((nesemnat) pThunk->ul Address fData)+ ) == ; Dacă (potrivire) returnează (nesemnat *) RVA Ptr(pImport->F rstThunk)+ : pThunk++: } returnează NULL: } FARPROC KPEFile;:SetImportAddress(LPCSTR pDllName LPCSTR pProcName, FARPROC pNewProc) { PIMAGE IMPORT DESCRIPTOR plmport= GetImportDescr ptor(pDlIName): Dacă (plmport) { const unsigned * pfn = GetFunctionPtrfpImport pProcName): Capitolul Principii și concepte de bază Dacă ( IsBadReadPtr(pfn, sizeof(DWORD)) ) returnează NULL: // Obține adresa sursă a funcției FARPROC oldproc = (FARPROC) * pfn; DWORD dwScris; // Înlocuiește cu noua adresă a funcției HackWriteProcessMemory(GetCurrentProcess() (vold*) pfn, & pNewProc, sizeof(DWORD) &dwWrltten); returnează oldproc: } el se returnează NULL; } SetlmportAddress folosește două funcții de ajutor Funcția GetlmportDescriptor caută în directorul de import și caută structura IMAGE IMPORT DESCRIPTOR pentru modulul din care este importată funcția Structura este transmisă funcției GetFunctionPtr, care caută tabelul indicii/nume și returnează adresa elementului corespunzător din tabelul adreselor importate De exemplu, dacă funcția MessageBoxA din user dll este importată, atunci funcția GetFunctionPtr trebuie să returneze adresa lui ітр MessageBoxA În cele din urmă, funcția SetlmportAddress citește adresa inițială a funcției și o înlocuiește cu noua adresă folosind funcția WriteProcessMemory După apelarea SetlmportAddress, toate apelurile către funcția de import specificată din modul vor fi trecute către noua funcție Astfel, funcția SetlmportAddress permite organizarea agățării apelurilor de funcții API Următorul este un exemplu simplu de utilizare a clasei KPEFile pentru a captura rezultatul unei casete de mesaj: int WINAPI MyMessageBoxA(HWND hWnd LPCSTR pText LPCSTR pCaption, UI NT uType) { WCHAR wText[MAX PATH]; WCHAR wCaption[MAX PATH]: MultiByteToWideChar(CP ACP, MB PRECOMPOSED, pText, - , wText, MAX PATH): wcscat(wText L" - interceptat"): MultiByteToWideChar(CP ACP MB PRECOMPOSED, pCaption - , wCaption, MAX-PATH): wcscat(wCaption, L” - interceptat"): return MessageBoxW(hWnd, wText, wCaption, uType); } Int WINAPI WinMain(HINSTANCE hlnstance HINSTANCE LPSTR int) { KPEFile pe(hlnstance): Format de fișier executabil Win pe SetlmportAddress("user dll" "MessageBoxA" (FARPROC)MyMessageBoxA); MessageBoxA(NULL „Test” „SetlmportAddress” MB OK): } Programul înlocuiește adresa importată a MessageBoxA din modulul curent cu adresa funcției MyMessageBoxA implementată de aplicația noastră, după care toate apelurile către MessageBoxA merg la MyMessageBoxA În exemplul nostru, această funcție adaugă cuvântul suplimentar „interceptat” la text și titlu și afișează o casetă de mesaj cu funcția MessageBoxW Export catalog Pentru ca programul dvs să importe o funcție/variabilă dintr-un DLL de sistem, acea funcție/variabilă trebuie să fie exportată corespunzător Pentru a exporta o funcție/variabilă dintr-o DLL, un fișier PE trebuie să conțină trei obiecte de date - un număr de secvență, o adresă și un nume opțional Toate informațiile legate de funcțiile exportate sunt combinate într-o structură IMAGE EXPORT DIRECTORY, care poate fi accesată prin directorul de export din antetul fișierului PE Deși atât funcțiile, cât și variabilele pot fi exportate, de obicei sunt exportate numai funcțiile Din acest motiv, chiar și numele câmpurilor din structurile fișierelor PE menționează doar funcții Structura IMAGE EXPORT DIRECTORY conține informații despre numărul de funcții de exportat și numărul de nume, care poate fi mai mic decât numărul total de funcții Majoritatea DLL-urilor exportă funcții după nume Unele DLL-uri (cum ar fi comctl dll) exportă unele funcții după nume, iar altele după număr Unele DLL-uri (cum ar fi DLL-ul MFC) exportă mii de funcții, așa că pentru a economisi spațiu pe nume, toate funcțiile sunt exportate după numărul de serie DLL-urile COM exportă un număr fix de funcții binecunoscute (cum ar fi DHRegisterServer) în timp ce oferă interfețe de serviciu sau tabele de funcții virtuale Unele DLL-uri nu exportă absolut nimic - folosesc doar punctul de intrare al DLL-ului Mai multe informații interesante din IMAGE EXPORT DIRECTORY includ tabele cu adrese de funcții RVA, tabele cu nume de funcție și tabele cu numere de secvență a funcției Tabelul de adrese conține RVA al tuturor funcțiilor exportate Tabelul de nume conține RVA a șirurilor de nume de funcție, iar tabelul de numere de secvență conține diferențele dintre numerele de secvență reale și de bază Cunoscând structura tabelului de export, puteți implementa cu ușurință funcția Get-ProcAddress Cu toate acestea, o astfel de implementare există deja în API-ul Win (din păcate nu are o versiune Unicode) În schimb, să încercăm să implementăm funcția KPEFile: :SetExportAddress După cum se arată mai sus, funcția SetlmportAddress modifică tabelul de import al modulului și modifică adresa unei funcții importate într-un modul Alte module de proces (inclusiv modulele încărcate ulterior de proces) nu sunt afectate de aceste modificări Funcția SetExportAddress Capitolul Principii și concepte de bază functioneaza diferit Modifică tabelul de export al modulului și, prin urmare, afectează toate instanțele funcției exportate în viitor Mai jos este codul funcției SetExportAddress FARPROC KPEFile::SetExportAddress(LPCSTR pProcName, FARPROC pNewProc) { PIMAGE-EXPORT-DIRECTORY pExport = (PIMAGE EXPORT DIRECTORY) GetDI rectory(IMAGE DIRECTORYJNTRY EXPORT); Dacă (pExport==NULL) returnează NULL; ordin nesemnat = ; Dacă ( (nesemnat) pProcName AddressOfNames); const WORD * pOrds = (const WORD *) RVA Ptr(pExport->Address fName rd nals); // Găsiți elementul cu numele funcției pentru (nesemnat = ; Address fNames; ++) Dacă ( str cmp(pProcName, RVA Ptr(pNames[ ]))== ) { // Obține numărul de secvență corespunzător ord = pExport->Base + pOrds[ ]; pauză; } } Dacă ( (ord Base) || (ord>pExport->Number fFunct ons) ) returnează NULL; // Folosiți numărul de ordine pentru a obține adresa, // prin care este stocat RVA-ul funcției exportate DWORD * pRVA = (DWORD *) RVA Ptr(pExport->AddressOfFunctlons) + ord - pExport->Base; // Citiți adresa sursei funcției DWORD rslt=*pRVA; DWORD dwWritten= ; DWORD newRVA = (DWORD) pNewProc - (DWORD) pModule: Wr teProcessMemory(GetCurrentProcess(), pRVA, & noua RVA slzeof(DWORD), & dwWritten); return (FARPROC) RVA Ptr(rslt); } Funcția SetExportAddress încearcă mai întâi să găsească numărul de index al funcției date Dacă numărul secvenței nu este specificat, numele funcției este căutat în tabel Arhitectura sistemului de operare Microsoft Windows nume de funcții Indexarea tabelului de adrese ale funcției prin ordinal oferă adresa unde este stocată RVA-ul funcției exportate Apoi SetExportAddress citește RVA original și îl înlocuiește cu unul nou calculat la noua adresă a funcției Ca rezultat al modificării tabelului de export după apelarea SetExportAddress, funcția GetProcAddress va returna adresa noii funcție Încărcările viitoare DLL de către proces se vor conecta cu noua funcție Nici SetlmportAddress, nici SetExportAddress nu asigură interceptarea completă a apelurilor API printr-un proces, dar utilizarea ambelor funcții împreună va rezolva foarte mult această problemă Ideea este simplă: parcurgem toate modulele încărcate în prezent de proces și apelăm SetlmportAddress pe fiecare Apoi este apelată funcția SetExportAddress, care modifică tabelul de export În acest caz, modificarea se aplică atât modulelor care sunt încărcate în prezent, cât și modulelor care vor fi încărcate în viitor Aceasta încheie scurta noastră introducere în formatul fișierului PE Materialul din această secțiune va fi folosit în explorarea spațiului virtual al utilizatorului în Capitolul și pentru interceptarea/monitorizarea apelurilor API în Capitolul Dacă sunteți cu adevărat interesat de fișierele PE și urmărirea API, luați în considerare dacă au mai rămas apeluri API care nu sunt afectate prin efectele apelurilor către SetlmportAddress și SetExportAddress Arhitectura sistemului de operare Microsoft Windows Luați carcasa cu sursa de alimentare, placa de bază, procesorul, memoria, hard diskul, unitatea CD-ROM, adaptorul video, tastatura și monitorul, asamblați-o într-o singură unitate - obțineți un computer Dar pentru ca un computer să facă ceva util, sunt necesare programe Programele de calculator sunt împărțite în mod convențional în programe de sistem și programe de aplicație Programele de sistem controlează funcționarea computerului și a dispozitivelor periferice, oferind astfel funcționarea programelor de aplicație care rezolvă problemele reale ale utilizatorilor Cel mai fundamental program de sistem este sistemul de operare, care gestionează toate resursele computerului și oferă o interfață convenabilă pentru lucrul cu programele de aplicație Echipamentul la care lucrăm (deși are mult mai multe capacități decât predecesorii săi) este programat la un nivel foarte primitiv și incomod Una dintre sarcinile principale ale sistemului de operare este de a simplifica programarea hardware-ului prin utilizarea unor funcții de sistem bine definite Funcțiile sistemului sunt implementate de sistemul de operare în modul privilegiat al procesorului; ele definesc interfața dintre sistemul de operare și programele utilizator care rulează în modul procesor neprivilegiat Microsoft Windows NT/ este oarecum diferit de sistemele de operare tradiționale Windows NT/ este format din două părți principale: Capitolul Principii și concepte de bază partea de mod nucleu privilegiat și partea de mod de utilizator neprivilegiat O parte din modul kernel al Windows NT/ rulează în modul procesor privilegiat, în care sunt disponibile toate instrucțiunile procesorului și întreg spațiul de adrese Pe procesoarele Intel, aceasta înseamnă rularea la nivelul de privilegii cu acces la GB de spațiu de adrese, spațiu de adrese I/O și așa mai departe O parte din modul utilizator al Windows NT/ rulează în modul procesor neprivilegiat, în care sunt disponibile doar un set limitat de instrucțiuni și o parte din spațiul de adrese Pe procesoarele Intel, codul în modul utilizator rulează la nivelul de privilegiu și are acces doar la cei GB inferioare din spațiul de adrese al procesului Porturile I/O nu sunt disponibile pentru acesta Partea mod kernel oferă utilizarea funcțiilor sistemului și proceselor interne de către partea modului utilizator Microsoft numește această parte „executiv” (executiv) Acesta este singurul punct de intrare în nucleul sistemului de operare; din motive de securitate, Microsoft a refuzat să creeze uși în spate Codul în modul kernel constă din următoarele componente principale: Despre HAL (Hardware Abstraction Layer) - un strat software care abstrage o parte din modul kernel din diferențele hardware specifice platformei; О microkernel (MicroKernel) - funcții de nivel scăzut ale sistemului de operare: programarea firelor, comutarea sarcinilor, gestionarea întreruperilor și a excepțiilor, sincronizarea multiprocesorului; О drivere de dispozitiv (Device Drivers) - drivere de hardware, sistem de fișiere și suport de rețea care implementează funcții I/O definite de utilizator; О management de ferestre și sistem grafic - implementarea funcțiilor GUI (ferestre, elemente, ieșire grafică și imprimare); Despre partea executivă - funcțiile de bază ale sistemului de operare: managementul memoriei, managementul fluxului de procese și programe, securitate, I/O și comunicații inter-procese Partea în modul utilizator a Windows NT/ constă de obicei din trei componente: O procese de sistem - procese speciale de sistem (de exemplu, procesul de înregistrare a utilizatorilor în sistem și managerul de sesiune); Despre servicii (servicii) - în special, servicii pentru înregistrarea evenimentelor și programare; O subsisteme de platformă - furnizează funcții ale sistemului de operare programelor utilizatorului prin API-uri bine definite Windows NT/ acceptă capacitatea de a rula Win , POSIX (Interfață de sistem de operare portabilă - standard internațional API nivel de sistem de operare C), OS/ (sistemul de operare IBM), DOS și Winl Arhitectura sistemului de operare Microsoft Windows HAL Stratul HAL (Hardware Abstraction Layer) este responsabil pentru suportul specific platformei pentru funcționarea nucleului NT, a managerului I/O, a depanatoarelor în mod kernel și a driverelor de dispozitiv de nivel scăzut Prezența HAL reduce dependența sistemului de operare Windows NT/ de o anumită platformă hardware sau arhitectură HAL oferă o abstractizare pentru adresarea dispozitivelor, arhitectura I/O, managementul întreruperilor, operațiunile de acces direct la memorie (DMA), ceasuri și temporizatoare ale sistemului, firmware, instrumente de interfață BIOS și gestionarea configurației La instalarea Windows NT/ , suportul HAL este oferit de modulul system \hal dll Dar, de fapt, există diferite module HAL pentru diferite arhitecturi; numai unul dintre ele este copiat în directorul de sistem și redenumit în hal dll Răsfoiți CD-ul de instalare Windows NT/ și veți găsi mai multe variante HAL pe acesta, cum ar fi halacpi dl , halsp dL și halmps dl Abrevierea ACPI înseamnă „Advanced Configuration and Power Interface” Pentru a afla ce caracteristici oferă HAL pe sistemul dumneavoastră, rulați comanda dumpbin hal dl /export Lista rezultată conține funcții exportate cum ar fi HalDisableSystemInterrupt, HalMakeBeep, HalSet-RealTimeClock, READ PORT UCHAR, WRITE PORT UCHAR etc Funcțiile exportate de HAL sunt documentate în Windows DDK, sub Kernel Mode Drivers, References, Part : Chapter Rutine de strat de abstracție microkernel Microkernel-ul (MicroKernel) din Windows NT/ gestionează resursa principală a computerului - procesorul Oferă suport pentru gestionarea întreruperilor și a excepțiilor, programarea și sincronizarea firelor, sincronizarea cu multiprocesor și sincronizarea Microkernel-ul își expune funcțiile clienților prin interfețe bazate pe obiecte, similare obiectelor și manipulatoarelor utilizate în API-ul Win Principalele obiecte suportate de microkernel sunt obiectele de expediere și control Obiectele dispecerului sunt destinate expedierii și sincronizării Acestea includ evenimente, mutexuri, cozi, semafore, fire și cronometre Fiecare obiect dispecer este într-o anumită stare - setat (semnalizat) sau resetat (nesemnalizat) Microkernel-ul conține funcții cărora le sunt transmise starea obiectelor de expediere ca parametri (KeWaitxxx) Firele de execuție ale programului în modul kernel sunt sincronizate prin așteptarea obiectelor de expediere sau a obiectelor în modul utilizator care conțin obiecte de expediere în mod kernel încorporate De exemplu, obiectele eveniment la nivel de utilizator din Win au obiecte eveniment la nivel de microkernel corespunzătoare Capitolul Principii și concepte de bază Obiectele de control sunt utilizate pentru a gestiona operațiunile în modul kernel (cu excepția operațiunilor de dispecerizare și sincronizare gestionate de obiectele de expediere) Obiectele de control includ apeluri de procedură asincronă (APC, Procedura asincronă Caii), apeluri de procedură amânată (DPC, Procedura amânată Caii), întreruperi și procese Un blocare de rotație este un mecanism de sincronizare de nivel scăzut definit la nivelul nucleului NT Acest mecanism este utilizat pentru sincronizarea accesului la resursele partajate, în special pe sistemele multiprocesor Când o funcție încearcă să achiziționeze o resursă, așteaptă până când blocarea este acordată fără a face vreo lucrare utilă Pe sistemul dvs , microkernel-ul se află în fișierul ntoskrnl exe Pe lângă microkernel, acest fișier conține partea executivă Există două versiuni ale microkernel-ului pe CD-ul de instalare: ntkrnlmp ex pentru sisteme cu multiprocesor și ntkrnlsp ex pentru sisteme cu un singur procesor Deși extensia este exe, modulul este de fapt un DLL Dintre cele câteva sute de funcții exportate de ntoskrnl exe, aproximativ aparțin microkernel-ului Numele tuturor funcțiilor suportate de microkernel încep cu prefixul „Ke” De exemplu, funcția KeAcquireSpinLock este concepută pentru a obține o blocare care asigură manipularea în siguranță a datelor partajate pe un sistem multiprocesor Funcția Kelni ti al i zeEvent inițializează o structură de evenimente la nivel de kernel, care poate fi apoi utilizată de funcțiile KeClearEvent, KeResetEvent și KeWaitForSingleObject Obiectele kernel sunt descrise în Windows DDK, sub „Drifere mod kernel, Ghid de proiectare, Partea , Capitolul : Obiecte NT și suport pentru drivere” Funcțiile kernelului sunt documentate în „Drifere pentru modul kernel, Referințe, Partea , Capitolul : Rutine kernel” Drivere de dispozitiv Deci, microkernel-ul controlează procesorul; HAL gestionează magistrala, DMA, temporizatorul, firmware-ul și BIOS-ul Dar pentru ca un computer să fie cu adevărat util, sistemul de operare trebuie să comunice cu o mare varietate de dispozitive, inclusiv un adaptor video, mouse, tastatură, hard disk, unitate CD-ROM, adaptor de rețea, porturi paralele și seriale și așa mai departe cu aceste dispozitive, sistemul de operare folosește drivere de dispozitiv Majoritatea driverelor de dispozitiv din Windows NT/ sunt drivere în modul kernel; excepțiile sunt Virtual Device Drivers (VDD) pentru aplicațiile MS-DOS și driverele de imprimantă în modul utilizator Windows Driverele de dispozitiv în modul Kernel sunt DLL-uri care sunt încărcate în spațiul de adrese kernel în funcție de configurația hardware și setările utilizatorului Interfața sistemului de operare Windows NT/ cu drivere de dispozitiv are o structură pe mai multe niveluri Aplicația utilizator apelează funcții API precum Win CreateFile, ReadFile, WriteFile și așa mai departe Apelurile sunt traduse în apeluri la funcții ale sistemului I/O suportate de Windows NT/ runtime Manager I/O împreună cu Arhitectura sistemului de operare Microsoft Windows Partea executivă creează pachete de solicitare I/O (IRP-uri, pachete de solicitare I/O) și le trimite către dispozitivul fizic prin driver (sau prin mai multe drivere situate la niveluri diferite) Windows NT/ definește patru tipuri de drivere în modul kernel cu structură și funcționalitate diferite Despre șoferul de cel mai înalt nivel Această categorie include în principal drivere de sistem de fișiere - în special drivere pentru sistemul de fișiere FAT (File Allocation Table) moștenit de la DOS, sistemul de fișiere NT (NTFS), sistemul de fișiere CD-ROM (CDFS), precum și drivere pentru server de rețea și redirector NT Un driver de sistem de fișiere poate implementa un sistem de fișiere fizic pe un hard disk local, dar poate implementa și un sistem de fișiere virtual distribuit sau de rețea De exemplu, unele sisteme de control al versiunilor codului sursă sunt implementate ca sisteme de fișiere virtuale Funcționarea șoferilor de nivel superior se bazează pe utilizarea șoferilor de nivel inferior A Drivere intermediare - drivere de disc virtual, drivere oglindă sau drivere specifice categoriei, drivere pentru stratul de transport de rețea, drivere de filtru Driverele intermediare fie oferă funcționalități suplimentare, fie efectuează operațiuni specifice pentru o anumită clasă de dispozitive De exemplu, există un driver de clasă pentru comunicarea printr-un port paralel Munca șoferilor intermediari se bazează și pe sprijinul șoferilor de nivel inferior O ierarhie poate include mai multe drivere intermediare A Drivere de nivel inferior, uneori denumite drivere de dispozitiv Exemple sunt driverul de magistrală PnP, driverele de dispozitiv NT vechi și driverul NIC (Network Interface Controller) A Mini-Driverele sunt module de configurare personalizate pentru drivere mai generale Mini driverul nu este un driver complet Acesta se află în interiorul unui „driver de ambalare” generic și este folosit pentru a-l personaliza pentru hardware specific De exemplu, Microsoft definește driverul de imprimantă universal UniDriver Producătorii de imprimante pot dezvolta mini-drivere pentru imprimantele lor, care vor fi încărcate de UniDriver pentru imprimarea pe o anumită imprimantă Driverul de dispozitiv nu se potrivește întotdeauna cu dispozitivul fizic Un driver de dispozitiv este o facilitate convenabilă care permite unui programator să scrie un modul care este încărcat în spațiul de adrese al nucleului Încărcarea unui modul în spațiul de adrese kernel deschide funcții utile care nu sunt disponibile în mod normal Operațiile de fișiere bine definite ale API-ului Win permit aplicației dvs în modul utilizator să interacționeze cu ușurință cu un driver în modul kernel De exemplu, www sysinternals com are câteva utilitare foarte utile pentru NT care vă permit să utilizați drivere de dispozitiv în modul kernel pentru a controla registry, fișier Capitolul Principii și concepte de bază sistem și porturi I/O Capitolul al acestei cărți prezintă un driver simplu în mod kernel care citește datele din spațiul de adrese kernel Îl vom folosi pe scară largă pentru a analiza structurile de date ale subsistemului grafic Windows Deși majoritatea driverelor de dispozitiv fac parte din stiva I/O gestionată de managerul de I/O de execuție și au o structură similară, unele drivere de dispozitiv sunt excepții Driverele de dispozitiv pentru motorul grafic Windows NT/ , cum ar fi driverul de afișare, driverul de imprimantă și driverul portului video, utilizează o structură diferită și sunt apelate direct Windows permite chiar și driverelor de imprimantă să ruleze în modul utilizator Driverele de afișare și driverele de imprimantă sunt discutate mai detaliat în Capitolul Majoritatea modulelor încărcate în spațiul de adrese kernel sunt drivere de dispozitiv Utilitarul de drivere din Windows NT/ DDK listează driverele într-o fereastră de sesiune DOS În această listă veți găsi driverul de comunicare în rețea tcpip sys, driverul mouse-ului mouclass sys, driverul tastaturii kbdclass sys, driverul CD-ROM cdrom sys etc Pentru informații complete despre driverele de dispozitiv Windows , consultați Windows DDK, secțiunea „Drifere pentru modul kernel, Ghid de proiectare și referințe” Sistem de gestionare a ferestrelor și grafică În timpul dezvoltării versiunilor timpurii ale Microsoft Windows NT, securitatea a fost considerată un factor cheie, astfel încât ferestrele și sistemul grafic rulau în spațiul de adrese al utilizatorului Acest lucru a cauzat atât de multe probleme de performanță încât, începând cu Windows NT , Microsoft a făcut o schimbare fundamentală în arhitectura sistemului și a mutat sistemul de ferestre și grafică din modul utilizator în modul kernel Sistemul de ferestre oferă principalele componente ale interfeței grafice Windows - clase de ferestre, ferestre, mecanism de procesare a mesajelor din fereastră, interceptare (conectare), proprietăți ale ferestrelor, meniuri, titluri ferestre, bare de defilare, pointeri mouse-ului, taste virtuale, clipboard (clipboard), etc e În esență, acesta este un analog la nivel de kernel al user dll, care implementează definițiile Win API din fișierul winuser h Sistemul grafic implementează ieșirea GDI/DirectDraw/Direct D pe un dispozitiv fizic sau pe o memorie Funcționarea sa se bazează pe drivere pentru dispozitive grafice, cum ar fi drivere de afișare sau drivere de imprimantă Sistemul grafic este conținutul principal al bibliotecii gdi dll, care implementează definițiile API Win din fișierul wingdi h În plus, sistemul grafic acceptă drivere de afișare și imprimante — oferă un motor complet de randare pentru suprafețele bitmap în mai multe formate standard Sistemul grafic este tratat în detaliu în Capitolul Sistemul de ferestre și sistemul grafic sunt ambalate într-un DLL mare win k sys de aproximativ , MB Dacă vă uitați prin lista de funcții exportate din win k sys, veți găsi puncte de intrare în sistemul grafic (de exemplu, EngBitBlt sau PATHOBJ bMoveTo), dar nu veți găsi niciunul Arhitectura sistemului de operare Microsoft Windows sistem de ferestre de intrare ki Ideea este că funcțiile de ferestre nu sunt apelate niciodată de alte componente ale nucleului sistemului de operare, iar funcțiile sistemului grafic trebuie apelate de driverele dispozitivelor grafice Bibliotecile gdi dll și user dll accesează win k sys prin funcțiile de sistem Partea executivă Microsoft definește Windows NT/ Executive ca colecția de componente în modul kernel care alcătuiesc sistemul de operare de bază Windows NT/Windows structură de proces, comunicare între procese (LPC și RPC), manager de obiecte, manager I/O, manager de configurare , și monitor de securitate Fiecare componentă de rulare acceptă un set de funcții de sistem care pot fi apelate din modul utilizator (cu excepția managerului de cache și a HAL) folosind întreruperi În plus, fiecare componentă oferă un punct de intrare care este disponibil numai pentru modulele care rulează în spațiul de adrese al nucleului Componenta Executive Support implementează un set de funcții numite din modul kernel Numele acestor funcții încep de obicei cu prefixul „Ex” Funcționalitatea principală a acestei componente este alocarea memoriei la nivel de kernel Windows NT/ utilizează două blocuri de memorie extensibile dinamic numite pool-uri pentru a gestiona alocarea dinamică a memoriei din spațiul de adrese în modul kernel Primul dintre acestea, pool-ul nepaginat, este garantat să rămână în memoria fizică în orice moment Fragmentele critice (cum ar fi gestionanții de întreruperi) pot folosi pool-ul nepaginat fără a fi nevoie să vă faceți griji cu privire la întreruperile din memorie Al doilea, grup paginat, are o dimensiune mult mai mare, dar dacă nu există suficientă memorie fizică, conținutul său poate fi paginat pe disc De exemplu, memoria pentru rasterele Win dependente de dispozitiv este alocată din pool-ul paginat utilizând familia de funcții ExAllocatePoolxxx Componenta de suport executiv oferă, de asemenea, o schemă eficientă de alocare a memoriei în blocuri de dimensiuni fixe - așa-numitele „liste „look-aside”, pentru care sunt folosite funcții precum ExAllocatePagedLookasideList Când sistemul pornește, mai multe liste de prezentare generală sunt alocate din pool-uri Componenta de suport executiv oferă o gamă bogată de operații atomice - ExInterlockedAddLargelnteger, ExInterlockedRemoveHeadList, InteriockedCompareExchange și așa mai departe Managerul de memorie oferă gestionarea memoriei virtuale, managementul setului de echilibru, maparea memoriei virtuale cu cele fizice etc Managerul de memorie acceptă funcții precum MmFreeContiguousMemory, MmGetPhysicalAddress, MmLockPageableCodeSection etc Capitolul Principii și concepte de bază Cache Manager oferă stocarea în cache a datelor pentru driverele de sistem de fișiere Windows NT/ Funcțiile managerului cache sunt prefixate cu „CC” Managerul de cache exportă funcții precum CcIsThereDirty-Data și CcCopyWrite Funcțiile componentei Structura procesului sunt concepute pentru a crea și a termina firele de execuție în modul kernel de sistem, precum și pentru a le notifica procesele/thread-urile și cererile de procesare către acestea De exemplu, managerul de memorie poate folosi funcția PsCreateSystemThread pentru a crea un fir de nucleu care scrie pagini murdare Managerul de obiecte gestionează comportamentul general al obiectelor suportate de runtime Partea executivă oferă crearea de obiecte pentru directoare, evenimente, fișiere, legături simbolice, temporizatoare și alte funcții, cum ar fi ZwCreateDirectoryObject și ZwCreateFile După ce obiectul este creat, funcțiile ObReferenceObject și ObDereferenceObject ale managerului de obiecte actualizează numărul de referințe, funcția ObReferenceObjectBy-Handle verifică mânerul obiectului și returnează un pointer către obiectul însuși Managerul I/O traduce cererile I/O de la programele în modul utilizator sau alte componente în modul kernel în secvența corectă de apeluri către diferite drivere Numărul de funcții suportate de această componentă este foarte mare De exemplu, funcția loCreateDevice inițializează un obiect dispozitiv pentru a fi utilizat de către driver, funcția loCallDriver transmite pachete de solicitare I/O către driverul de nivel inferior următor, iar funcția loGetStackLimits verifică limita stivei firului de execuție curent al programului Windows NT/ runtime menține, de asemenea, o mică bibliotecă de rulare similară cu biblioteca de rulare C, dar mult mai mică Biblioteca de rulare a nucleului oferă conversii Uni-code, operații pe biți, operații de memorie și de număr mare, acces la registry, conversie de timp, operații cu șiruri etc Pe Windows NT/ , runtime-ul și microkernel-ul sunt împachetate într-un singur modul ntoskrnl exe care exportă peste de puncte de intrare Funcțiile exportate de ntoskrnl exe încep de obicei cu un prefix de două litere, care este o indicație a componentei la care se referă funcția De exemplu, prefixul „CC” înseamnă manager de cache, „Io” - manager I/O, „Ke” - microkernel, „Ob” - manager de obiecte, „Rtl” - bibliotecă de execuție, „Dbg” - suport de depanare etc Funcțiile sistemului Funcționalitatea bogată susținută de nucleul sistemului de operare Windows NT/ este furnizată modulelor în modul utilizator printr-un „gateway” îngust Pe procesoarele Intel, aceasta este întreruperea x E Întreruperea este asigurată de funcția KiSystemService, care se află în fișierul ntoskrnl exe, dar nu este exportată Deoarece handlerul de întrerupere rulează în modul kernel, procesorul trece automat în modul privilegiat, ceea ce face posibilă accesarea spațiului de adrese kernel Arhitectura sistemului de operare Microsoft Windows Deși în timpul apelului este utilizat un singur număr de întrerupere, numărul necesar de peste de funcții de sistem Windows NT/ este specificat în registrul EAX (pentru procesoarele Intel) Programul ntoskrnl exe menține un tabel de funcții de sistem numit KiServiceTable; win k sys are propriul său tabel W pServiceTable Tabelele de funcții ale sistemului sunt înregistrate prin apelarea KeAdd-SystemServiceTable Când KiSystemService primește un apel de funcție de sistem, verifică dacă indexul funcției de sistem este valid și dacă parametrii așteptați sunt disponibili, apoi transmite apelul handler-ului funcției de sistem Să ne uităm la exemple de funcții de sistem din depanatorul Microsoft Visual C++ folosind fișierele simbol de depanare Windows Dacă urmați apelul CreateHalftonePalette în Win GDI, veți vedea următorul fragment: NtGdiCreateHalftonePalette@ : mutare eax, h lea edx, [esp+ ] Int Eh ret Funcția personalizată Win GetDC este implementată după cum urmează: NtUserGetDC@ : mov eax, bh lea edx, [esp+ ] int Eh ret Funcția kernel Win CreateEvent este mai complexă CreateEventA apelează funcția CreateEventW, care la rândul său apelează NtCreateEvent din ntdll dll Implementarea NtCreateEvent arată astfel: NtCreateEvent@ : mov eax, lEh lea edx, [esp+ ] int Eh retragere h Apelurile către funcțiile sistemului Windows NT/ sunt aproape complet ascunse de programatori Depanatorul SoftICE/W al Numega oferă comanda ntcall, care vă permite să obțineți informații despre unele funcții ale sistemului kernelului Pentru mai multe informații despre funcțiile sistemului, consultați articolul „Inside the Native API” al lui Mark Russinovich la www sysinternals com Funcțiile sistemului CGI vor fi descrise mai detaliat în Capitolul Procesele de sistem Sistemul de operare Windows NT/ are mai multe procese de sistem care gestionează conectarea utilizatorului, serviciile și procesele utilizatorului Lista proceselor de sistem poate fi vizualizată în managerul de activități; De asemenea, puteți utiliza utilitarul tlist inclus cu Platform SDK Capitolul Principii și concepte de bază Când Windows NT/ rulează, există trei ierarhii de proces Prima ierarhie constă dintr-un singur proces de sistem, al cărui ID este întotdeauna A doua ierarhie include toate celelalte procese de sistem Începe cu un proces numit system, care este părintele procesului manager de sesiune (smss exe) Procesul manager de sesiune este părintele procesului subsistemului Win (csrss exe) și al procesului de conectare a utilizatorului (winlogon exe) A treia ierarhie începe cu procesul manager de program (explorer exe), care este părintele tuturor proceselor utilizatorului Arborele de proces Windows afișat de comanda tlist -t arată astfel: Proces de sistem ( ) Sistem ( ) smss exe ( ) csrss exe ( ) winlogon exe ( ) services exe ( ) Proces inactiv sistemului manager de sesiune W n Controler de serviciu de proces de conectare la serverul subsistemului svchost exe ( ) spoolsv exe ( ) svchost exe ( ) mstask exe ( ) FEREASTRA COM AGENT DE SISTEM lsass exe ( ) server local de autentificare de securitate explorer exe ( ) Manager de programe OSA EXE ( ) Memento IMGICON EXE ( ) Utilitarul Process Walker (pwalker exe) afișează informații suplimentare despre fiecare proces Process Walker arată că System Idle Process constă dintr-un singur thread de program cu o adresă de pornire de Este posibil ca acesta să nu fie un proces real, ci un mecanism prin care se organizează o perioadă de așteptare pasivă în sistem Procesul System are o adresă validă în spațiul de adrese kernel și constă din zeci de fire de execuție cu adrese de pornire care aparțin spațiului de adrese kernel Prin urmare, procesul de sistem este, de asemenea, părintele firelor de execuție de sistem în modul kernel Dacă convertiți adresele de început ale acestui proces în nume simbolice, veți găsi destul de multe nume interesante precum Phasel-Initialization, ExpWorkerThread, ExpWorkerThreadBalanceManager, MiDereferenceSegment-Thread, MiModifiedPageWriter, KeBalancedSetManager, FsTRtrea, etc de partea de execuție, firele de execuție ale nucleului pot fi create de alte componente ale nucleului Dar procesele sistemului Idle și System sunt componente „pure” în modul kernel, fără module în spațiul de adrese în modul utilizator Alte procese de sistem (manager de sesiune, proces de conectare a utilizatorului etc ) sunt procese în modul utilizator lansate din fișierele PE De exemplu, smss exe, csrss exe și winlogon exe se află în directorul de sistem Windows Arhitectura sistemului de operare Microsoft Windows Servicii Microsoft Windows NT/ are o categorie specială de aplicații numite servicii De obicei, acestea sunt programe de consolă gestionate de SCM (Service Control Manager) și care oferă anumite servicii Serviciile, spre deosebire de programele de utilizator obișnuite, pot fi pornite automat în timpul pornirii sistemului, înainte ca utilizatorul să se conecteze la acesta Pentru a obține o listă de servicii care rulează în prezent pe sistemul dvs , rulați utilitarul Lista de activități (tlist exe) cu opțiunea -s Mai jos este un exemplu de listă de servicii și utilități Svcs services exe: AppMgmt, Browser dmserver Dnscache, EventLog, LanmanServer, LanmanWorkstatlon LmHosts, Messenger PlugPlay, ProtectedStorage, seclogon TrkWks lsass exe svchost exe spoolsv exe svchost exe Svcs: PolicyAgent, SamSs Svcs: RpcSs Svcs: Spooler Svcs: EventSystem Netman, NtmsSvc RasMan SENS TapiSrv mstask exe Svcs: Program Dintre aceste servicii, suntem interesați în special de spooler, care procesează lucrările de imprimare pe computerele locale și le trimite la imprimantă prin rețea Serviciul spooler este tratat mai detaliat în Capitolul Subsisteme platforme În primele etape ale evoluției Windows NT, nu existau multe programe Win scrise special pentru acel sistem Din acest motiv, Microsoft a decis că platforma Windows NT ar trebui să suporte capacitatea de a rula programe DOS, Winl , OS/ , POSIX (cu o interfață în stil UNIX) și Win Pentru a rula astfel de programe diferite pe Windows NT/ , există mai multe subsisteme diferite de platformă Un subsistem de mediu este un set de procese și DLL-uri care oferă un subset de funcționalități ale sistemului de operare pentru aplicațiile scrise pentru un anumit subsistem Fiecare subsistem are un proces care gestionează interacțiunea cu sistemul de operare (server) Maparea unui DLL la procesele de aplicație permite interacțiunea cu un proces subsistem sau direct cu nucleul prin funcțiile sistemului OS Treptat, subsistemul Win a preluat conducerea printre subsistemele suportate de familia Windows NT/ Toate operațiunile de ferestre și grafică din spațiul de adrese ale utilizatorului sunt efectuate prin serverul subsistemului Win (csrss exe) Programele de aplicație pentru a efectua aceste operațiuni trebuie să acceseze procesul subsistemului prin mecanismul LPC, care afectează negativ performanța Începând de la Win Capitolul Principii și concepte de bază Dows NT , Microsoft a mutat DLL-ul în modul kernel, win k sys, cea mai mare parte a subsistemului platformei Win , împreună cu toate driverele pentru dispozitive grafice, în DLL-ul în modul kernel DLL-urile subsistemului Win sunt foarte familiare tuturor programatorilor Windows Biblioteca kernel dll gestionează memoria virtuală, I/O, heap-ul, procesele, firele de execuție și sincronizarea; user dll oferă ferestre și transmiterea mesajelor; gdi dll implementează ieșirea și imprimarea grafică; advapi dll este responsabil pentru operațiunile de registry etc DLL-urile subsistemului Win oferă acces direct la funcțiile sistemului de kernel al sistemului de operare și oferă caracteristici suplimentare utile care nu sunt acceptate de funcțiile sistemului OS Un exemplu de caracteristici API Win care nu sunt suportate direct de win k sys sunt Metafiles îmbunătățite (EMF) Celelalte două subsisteme de platformă, OS/ și POSIX, se bazează pe subsistemul Win , deși au fost considerate la egalitate cu Win atunci când Windows NT a fost proiectat inițial Acum, subsistemul platformei Win a devenit o parte integrantă, care rulează constant, a sistemului de operare Subsistemele OS/ și POSIX sunt rulate numai atunci când este necesar pentru funcționarea unor programe specifice Rezultate Acest capitol acoperă pe scurt elementele de bază ale programării Windows C++ Am analizat exemplele celor mai simple programe C++ și ne-am familiarizat cu limbajul de asamblare și mediul de programare, formatul de fișier executabil Win și arhitectura sistemelor de operare Microsoft Windows NT/ Începând cu capitolul , accentul se va pune pe programarea grafică Windows NT/ Cu toate acestea, dacă este necesar, vom crea mici instrumente auxiliare care ne simplifică cercetarea Informații utile despre subiectele abordate aici pot fi găsite pe Internet, cum ar fi la www codeguru com, www codeproject com și www msdn microsoft com Pagina web www systeminternals com are multe articole informative, utilitare și exemple de programe pentru a vă ajuta să vă explorați sistemul Intel a deschis o pagină web pentru dezvoltatori unde puteți afla mai multe despre procesoarele Intel, optimizarea programelor, magistrala AGP, compilatorul Intel C++ etc Pagina web Adobe este pentru oricine are talentul necesar pentru a crea plugin-uri (plug-in-uri) și filtre la aplicațiile Adobe Mulți producători de adaptoare video au și propriile lor pagini web pentru dezvoltatori Exemple de programe Textele complete ale programelor prezentate în acest capitol se află pe CD-ul însoțitor (Tabelul ) Rezultate Tabelul Exemple de programe din capitolul Descriere director de proiect Sample\Chart \Hellol Program "Hello, World" - Lansare browser Sample\Chart \Hello Programul „Hello, World” - Afișarea textului pe desktop Sample\Chart \Hello Programul „Hello, World” - o clasă de ferestre simplă Sample\Chart \Hello Programul „Hello, World” - Încețoșarea textului utilizând DirectDraw Sample\Chart \GDISpeed Utilizarea asamblatorului pentru sincronizare Sample\Chart \SetProc Interceptarea ușoară a funcțiilor API prin modificarea directoarelor de import/export din fișierul PE Capitolul Arhitectura grafică Windows Sistemul grafic este o parte integrantă a tuturor sistemelor de operare moderne, care folosesc din ce în ce mai mult o interfață grafică intuitivă pentru a deveni mai accesibilă utilizatorului obișnuit Printre acestea se numără Windows NT/ Capitolul sa încheiat cu o scurtă descriere a arhitecturii sistemului de operare Windows NT/ Acest capitol se concentrează pe sistemul grafic ca o componentă separată a sistemului de operare Se discută componentele sistemului grafic și relațiile dintre ele - API-ul GDI, API-ul DirectDraw, API-ul OpenGL, motorul grafic, driverele de ecran și de imprimare, sistemul de imprimare și spooling Vom analiza, de asemenea, structura verticală a sistemului grafic Windows, și anume DLL-uri de sistem în modul utilizator care furnizează apeluri de funcție de sistem, mecanismul în modul kernel și drivere de dispozitive grafice terțe Capitolul se încheie cu un exemplu de driver de imprimantă simplu care generează rezultate ca pagină HTML Componente grafice Windows Interfața de programare a aplicațiilor Windows – sau mai simplu, API-ul Windows – este o colecție imensă de funcții interconectate care oferă diverse servicii programelor de aplicație Din punct de vedere al programatorului, API-ul Win este împărțit în mai multe grupuri în funcție de tipul de serviciu oferit Funcțiile Windows de bază, denumite în mod obișnuit ca un serviciu kernel - depanare, tratarea erorilor, biblioteci de linkuri dinamice (DLL), procese, Componente grafice Windows fire de execuție, fișiere, I/O, comunicare între procese, securitate etc O interfață cu utilizatorul este denumită în mod obișnuit un serviciu de utilizator - gestionarea ferestrelor, cozile de mesaje, casetele de dialog, controalele, controalele standard, casetele de dialog standard, resursele, intrarea utilizatorului, shell etc A Caracteristici grafice și multimedia - managementul culorilor, DirectX, GDI, Video pentru Windows, Still Image, OpenGL, Windows Media etc Despre caracteristicile COM, OLE și ActiveX - Component Object Model (COM), Automation, Microsoft Transaction Server, OLE (Object Link and Embedding), etc O bază de date și funcții de mesagerie - DAO (Data Access Objects), SQL Server, MAPI (Messaging API), etc A Rețea și funcții distribuite - Active Directory, coadă de mesaje, rețea, RPC, rutare și acces la distanță, server SNA (Systems Network Architecture), ȚAPI (Telephony API), etc Un Internet, intranet și extranet - Internet Explorer, Microsoft Agent, NteShow, scripturi, Site Server etc A Funcții de configurare și gestionare a sistemului - configurare, configurare, gestionare a sistemului etc Fiecare grup de funcții este susținut de un set specific de componente ale sistemului de operare Acestea includ DLL-uri ale subsistemului platformei Win , drivere pentru modul utilizator, funcții de sistem și drivere pentru modul kernel Pentru fiecare grup ar putea fi scrisă o carte voluminoasă cu informațiile necesare pentru a o utiliza eficient Grupul de funcții grafice și multimedia ale Win API este atât de mare încât ar fi nevoie de mai multe cărți groase pentru a-l descrie la nivelul potrivit Cartea pe care o citiți în prezent tratează un subset foarte important al acestui grup, și anume GDI și DirectDraw Să aruncăm o privire mai atentă asupra componentelor care oferă funcții grafice și multimedia GUI Win a fost implementat pe mai multe platforme, inclusiv Windows / , WinCE, Windows NT și noul Windows Anterior, sistemele din familia NT aveau un suport GDI mai bun deoarece foloseau implementări complete pe de biți, în timp ce sistemele din familia Windows a oferit un suport mai bun pentru programarea jocurilor Cu toate acestea, noul sistem de operare Windows a luat tot ce este mai bun din ambele familii Windows a introdus modificări semnificative pentru a suporta accelerarea hardware DirectX/OpenGL, o nouă interfață STI (Imagine statică), drivere de imprimantă în modul utilizator și așa mai departe În această carte, ne vom concentra pe arhitectura grafică și media Windows , diferențe din Windows / și Windows NT / vor fi evidențiate din când în când Capitolul Arhitectura grafică Windows Privind Fig devine clar că sistemul grafic și multimedia al Windows NT/ , ca și sistemul de operare în ansamblu, este format din mai multe niveluri Caseta de sus ilustrează programe de aplicație care interacționează cu un set de DLL-uri de sistem în modul utilizator pe de biți prin intermediul API-ului Win Stratul DLL de sistem conține bibliotecile deja familiare: gdi dll (GUI), user dll (Interfața utilizatorului și gestionarea ferestrelor), kernel dll (Serviciile de bază Windows), etc Majoritatea modulelor din acest strat sunt acceptate de sistem de operare, dar unele componente sunt acceptate de drivere în modul utilizator implementate de producătorii de hardware Mai jos este o poartă de acces pentru apelarea funcțiilor sistemului, prin care sunt apelați handlere care sunt în partea de mod kernel Runtime-ul Windows NT/ care rulează în spațiul de adrese kernel oferă suport general pentru sistemul grafic și multimedia sub forma unui motor grafic, manager I/O, driver de port video etc Are nevoie de suport de la driverele de dispozitiv furnizate de dezvoltatorii hardware , care interacționează cu diverse componente hardware (autobuz, adaptor video, imprimantă etc ) prin stratul HAL Aplicații Win personalizate Modul utilizator Funcțiile sistemului | Modul I/O Manager MCD Server Graphics Engine (DirectDraw, DDML) Port video (AGP) Driver de autobuz Port video mini (VPE, DxApi, TV) Driver de imagine statică Driver de afișare (DirectDraw, Direct D, MCb) Driver de font Driver de imprimantă Driver pentru portul de imprimantă Fonturi HAL Autobuz, monitor, cameră, scaner, imprimantă și echipamente de rețea nuclee Orez Arhitectura sistemului grafic și multimedia în Windows Acum să „plimbăm” pe orizontală partea din modul utilizator GDI (Graphics Device Interface, interfața dispozitivului grafic) și ICM (Image Color Management, sistem de management al culorilor) oferă independent de hardware Componente grafice Windows interfață de programare grafică suspendată pentru aplicații La ieșirea către o imprimantă, GDI vorbește cu driverul de imprimantă, care în Windows poate rula în modul utilizator Driverele de imprimantă în modul utilizator depind în mare măsură de caracteristicile suportate de motorul grafic Lucrările de imprimare sunt gestionate de un proces special de sistem numit spooler Folosește componente specializate care pot fi modificate de către producătorul de echipamente, inclusiv procesorul de imprimare (procesorul prinț), monitorul de imprimare (monitorul prinț) și furnizorul de imprimare (furnizorul prinț) DirectX adaugă un set relativ nou de DLL-uri de sistem Win la această schemă care implementează interfețele COM DirectX Interacțiunea reală cu implementarea DirectX în spațiul de adrese kernel are loc prin GDI DirectX include următoarele componente: DirectDraw, DirectSound, Direct-Music, DirectInput, DirectPlay, DirectSetup, AutoPlay și Direct D În această carte, dintre toate componentele DirectX, este luat în considerare doar DirectDraw GDI și DirectDraw vor fi descrise mai detaliat mai jos Între timp, să aruncăm o privire rapidă la alte componente care nu vor fi incluse în carte Multimedia Partea multimedia a API-ului Win este o evoluție a instrumentelor multimedia care au apărut pentru prima dată în Windows Acestea includ MCI (Media Control Interface), ieșire audio, operațiuni I/O în fișiere multimedia, control cu joystick și cronometre multimedia Interfața MSI controlează toate mediile de redare liniare; oferă funcțiile de încărcare, pauză, redare, înregistrare, oprire, continuare etc Sunt acceptate trei tipuri de ieșire audio: semnal CD audio, MIDI (Musical Instrument Digital Interface) și semnal digitizat (forma de undă) Funcțiile multimedia Win sunt definite în fișierul mmsystem h; biblioteca de funcții importate este conținută în winmm lib și winmm dll Funcționarea winmm dll se bazează pe driverele de dispozitiv în modul utilizator care sunt instalate pentru fiecare dispozitiv media Funcția principală exportată a driverului de dispozitiv media, care este un DLL pe de biți, este funcția DriverProc care gestionează mesajele din sistemul media - DRV OPEN, DRV ENABLE, DRV CONFIGURE, DRV CLOSE etc NOTĂ - Pentru a vedea ce drivere media sunt disponibile, deschideți fișierul mmdriver inf din directorul %SystemRoot%\system Enumeră aproximativ o duzină de șoferi De exemplu, driverul mmdrv dll oferă operațiuni de nivel scăzut cu un semnal digitizat, suport pentru MIDI și AUX (Aixi-IAgy Output Device, un dispozitiv de ieșire suplimentar) Microsoft Audio Compression Manager se află în fișierul msacm drv, iar fișierul ir dll conține codecul Indeo, un compresor/decompresor de date video dezvoltat de Intel și care utilizează un algoritm de compresie a semnalului digitizat cu suport MMX Capitolul Arhitectura grafică Windows Poate vă întrebați cum driverele în modul utilizator pot controla dispozitivele? De la sine nu pot Driverele media în modul utilizator folosesc o clasă specială de drivere în modul kernel numite drivere de streaming kernel care pot controla hardware-ul direct Partea multimedia a Win este înlocuită treptat de componentele DirectX corespunzătoare, care au caracteristici îmbunătățite și performanță mai rapidă De exemplu, DirectSound oferă înregistrarea și redarea sunetului într-un format de semnal digitizat; DirectMusic vă permite să salvați și să redați mostre digitale, inclusiv în format MIDI; DirectInput acceptă o gamă largă de dispozitive de intrare, inclusiv șoareci, tastaturi, joystick-uri și alte controlere de joc, precum și dispozitive cu feedback activ (force-feedback) Una dintre funcțiile multimedia utilizate în mod obișnuit de aplicațiile Windows obișnuite pentru a crea temporizatoare de înaltă rezoluție este funcția timeGetTimeO Are o precizie de milisecundă, ceea ce este de obicei mai bun decât funcția GetTickCount ( milisecundă pe Windows , milisecunde pe Windows NT/ ) În programele Win , funcția QueryPerformanceCounter oferă ordine de mărime o precizie mai mare decât funcțiile timeGetTime și GetTickCount (dacă procesorul acceptă contoare de înaltă rezoluție) La calculatoarele cu procesor Intel Pentium, contorul de înaltă rezoluție este contorul de ciclu al procesorului, care a fost menționat în Capitolul Prin urmare, pe un procesor de MHz, măsurătorile se fac cu o precizie de nanosecunde Cu toate acestea, apelarea QueryPerformanceCounter nu oferă o astfel de precizie; pentru a citi contorul, se folosește un acces la nucleul sistemului de operare printr-o funcție de sistem Video pentru Windows La fel ca toate mediile Win , Video pentru Windows are o istorie lungă, care se întorc în era Windows Video pentru Windows (VFW) oferă suport Win API pentru procesarea video Mai precis, acceptă AVI (Audio-Video Interleaved), citirea, scrierea, poziționarea și editarea fișierelor, managerul de compresie a datelor video, captura video și API-ul DrawDib Multe caracteristici VFW au fost înlocuite de DirectShow, una dintre componentele DirectX API-ul DrawDib conține funcții precum DrawDibDraw, DrawDibGetBuffer, Draw-DibUpdate etc Acest API este similar ca funcționalitate cu funcția Win StretchDIBits, dar acceptă funcții suplimentare, cum ar fi selecția decodorului, fluxul de date și (probabil) viteză mai mare Primele două posibilități sunt oferite de driverele de dispozitiv media instalabile care deservesc fluxuri de date diferite; a treia posibilitate, desigur, nu se compară cu posibilitățile DirectDraw În Win , suportul VFW este oferit de fișierul antet vfw h, fișierul de bibliotecă vfw lib și DLL-ul msvfw dll Implementarea VFW se bazează pe utilizarea părții multimedia a Win Componente grafice Windows NOTĂ - Funcțiile DrawDib sunt încă prezentate ca un instrument de desen rapid care nu utilizează GDI și scrie date direct în memoria video Sună bine, dar nu mai este adevărat, mai ales pe Windows NT/ Pe Windows NT/ , unde accesul direct la memoria video este posibil numai prin driverul DirectX în modul kernel, DrawDibDraw desenează DIB folosind funcția GDI și, prin urmare, este mai lent decât funcția de desen GDI DIB imagine statica Still Image (STI) este noua interfață Microsoft pentru captarea imaginilor statice digitale de pe dispozitive precum scanere și camere digitale Este disponibil numai pe Windows și Windows Desigur, STI înlocuiește standardul TWAIN mai vechi (Apropo, mă întreb de ce nu s-a numit DirectImage? Probabil că va fi în curând ) Noutatea relativă a acestui standard a oferit Microsoft luxul de a implementa STI folosind interfețe COM în loc de funcțiile tradiționale Win API Microsoft STI constă dintr-un monitor de evenimente, mini-drivere pentru modul utilizator furnizate de producător de hardware și un scaner sau panou de control al camerei Monitorul de evenimente la nivel de sistem monitorizează dispozitivele de intrare a imaginilor statice și evenimentele acestora De asemenea, menține o listă a aplicațiilor de procesare a imaginilor statice înregistrate care pot fi lansate automat atunci când este detectat un eveniment Minidriverul detectează evenimente de pe un anumit dispozitiv și notifică monitorul de evenimente despre ceea ce se întâmplă În plus, transmite datele de imagine de la driverul modului kernel în modul utilizator Folosind panoul de control al scanerului/camerului foto, utilizatorul asociază dispozitivele de captare a imaginilor statice cu aplicații care le acceptă Aplicația panoului de control al scanerului/camerului foto (sticpl dll), monitorul (stimon dll, stisvc exe) și aplicațiile de procesare a imaginilor statice folosesc toate obiectul STI COM (CLSID Sti) care implementează interfața IStillImage, care este instanțiată de Instanță de creare a funcției St Obiectul STI COM este implementat în biblioteca sti dll, care utilizează interfețele COM IStiDevice și IStiDeviceControl pentru a gestiona mini-driverele Pe Windows / , API-ul STI este acceptat de fișierul antet sti h, fișierul de bibliotecă sti lib, DLL-urile și EXE-urile menționate mai sus și driverele de dispozitiv corespunzătoare în modul utilizator și în modul kernel OpenGL Ultima componentă a modului utilizator prezentată în Fig este OpenGL, un standard de programare grafică D/ D dezvoltat de Silicon Graphics, Inc Scopul său principal este de a reda obiecte D/ D într-un cadru tampon OpenGL permite programatorului să descrie obiecte ca o colecție de vârfuri, fiecare definit de coordonate, culoare, normal, coordonate de textură și un steag de margine Astfel, folosind funcția Capitolul Arhitectura grafică Windows Ionii OpenGL pot descrie puncte individuale, segmente de linie și suprafețe D Instrumentele grafice OpenGL vă permit să setați transformări, coeficienți ai ecuațiilor de iluminare, metode de antialiasing și operatori de actualizare a pixelilor Înainte de redarea finală a datelor în framebuffer, procesul de randare OpenGL trece prin mai multe etape În etapa de calcul, curbele și suprafețele sunt aproximate folosind comenzi polinomiale La a doua etapă (operații cu vârfuri și asamblare primitivă), se efectuează transformări, se calculează iluminarea și are loc tăierea vârfurilor A treia etapă (rasterizare) generează o secvență de adrese framebuffer și valori asociate Ultima etapă (operații cu fragmente) efectuează buferul de adâncime, maparea alfa, mascarea și alte operațiuni la nivel de pixel în tamponul de cadre final După cum sa văzut în Windows NT/ , Microsoft a adăugat câteva caracteristici suplimentare la implementarea sa OpenGL Un set complet de comenzi OpenGL, OpenGL Utility (GLU) și OpenGL Programming Guide Auxiliary Library, Window extension (WGL), format de pixeli la nivel de fereastră și dublu buffering sunt implementate OpenGL folosește trei fișiere antet în subdirectorul di al directorului antet al compilatorului: gl h, glaux h și glu h WGL este definit în fișierul antet GDI wingdi h OpenGL folosește fișierele de bibliotecă opengl lib și gdi lib, precum și DLL-urile de rulare opengl dll și gdi dll Pentru a îmbunătăți performanța OpenGL, implementarea permite driverelor furnizate de furnizorul de hardware să efectueze optimizări specializate și să acceseze hardware direct Pentru confortul driverelor OpenGL, Microsoft acceptă o arhitectură mini-client (MCD) OpenGL dll încarcă mcd dll, un DLL client furnizat de sistemul de operare și un driver opțional OpenGL în modul utilizator furnizat de producătorul hardware Pentru a găsi driverul dvs OpenGL, căutați în registru OpenGLDrivers Clientul MCD și driverul OpenGL în modul utilizator utilizează caracteristica GDI Ext-Escape pentru a trimite comenzi către motorul grafic și driverul în modul kernel Suportul pentru partea MCD necesită un driver de ecran care oferă optimizări OpenGL cu suport pentru serverul MCD la nivel de kernel din mcdsrv dll Este destul de obișnuit în zilele noastre ca producătorii de adaptoare video să accepte accelerarea hardware DirectDraw, Direct D și OpenGL în același pachet Este întotdeauna interesant să vedem cum sunt folosite diferite arhitecturi (în acest caz GDI și OpenGL) în scopuri similare Inițial, GDI a fost conceput ca o interfață grafică simplă de programare, orientată către echipamentele standard ale industriei de PC-uri a vremii - și anume, adaptoare video EGA și VGA de și de culori, precum și imprimante alb-negru Treptat, GDI a adăugat suport pentru bitmap-uri independente de dispozitiv, imprimante color, fonturi vectoriale, fonturi TrueType și OpenType, spațiu de coordonate logice pe de biți, umpleri în gradient, canale alfa, suport pentru lucrul pe mai multe monitoare sau terminale etc Evoluția GDI continuă și acum GDI funcționează atât pe dispozitive miniaturale, cum ar fi computerele notebook (palmtop), cât și Componente grafice Windows și stații de lucru puternice Principalele obiective de proiectare pentru GDI (și API-ul Windows în general) au fost viteza, compatibilitatea cu versiunea anterioară și independența hardware Pe de altă parte, OpenGL a fost conceput ca un pachet grafic D/ D de înaltă performanță pentru redarea imaginilor realiste Datorită utilizării intense a calculelor în virgulă mobilă, OpenGL necesită un computer puternic, cu o cantitate mare de memorie și un procesor puternic Efecte precum iluminarea, ditheringul, ditheringul și aburirea pe un monitor VGA cu de culori vor fi ineficiente Deși interfața OpenGL a fost concepută pentru a fi independentă de dispozitiv, se concentrează în primul rând pe randarea imaginilor într-un framebuffer, astfel încât imprimarea pe imprimante de înaltă rezoluție este asociată cu unele dificultăți Apropo, în Windows NT/ GDI oferă o soluție la problemele de imprimare în OpenGL - comenzile OpenGL sunt scrise într-un format EMF special și apoi reproduse pe o imprimantă de înaltă rezoluție Datorită complexității redării D/ D, OpenGL este o interfață grafică de nivel mai înalt decât programele GDL OpenGL descriu de obicei o scenă în D folosind vârfuri, segmente de linie și suprafețe poligonale, definesc atribute, lumini și unghiuri de vizualizare și apoi continuă cu lucrări tehnice suplimentare la motorul OpenGL În GDI, o aplicație construiește o imagine apelând secvența dorită de comenzi cu parametrii corecti Dacă doriți să creați o imagine D, GDI nu vă va ajuta la calcularea adâncimii imaginii și la îndepărtarea suprafețelor ascunse Chiar și Modul Imediat al Direct D este o interfață de nivel scăzut în comparație cu OpenGL Windows Media Windows Media este o nouă adăugare la sistemul grafic/multimedia Win , constând din Windows Media Services, Windows Media Encoder, Windows Media Player Control și Windows Media Format SDK Serviciile Windows Media conțin controale ActiveX și interfețe COM care permit autorilor paginilor Web să transmită în flux informații audio și video și să controleze difuzarea acesteia Windows Media Encoder este în primul rând responsabil pentru conversia diferitelor tipuri de conținut media în fluxuri sau fișiere în format Windows Media, care sunt apoi livrate folosind Windows Media Services Fișierele container ASF (Advanced Streaming Format) pot conține date corespunzătoare diferitelor formate ale media sursă Windows Media Player Control este un control ActiveX pentru redarea media în aplicații și pagini Web Windows Media Format SDK oferă posibilitatea de a citi, scrie și edita fișiere Windows Media (audio, video și scripturi) Capitolul Arhitectura grafică Windows Componentele modului Kernel Componentele grafice și multimedia în modul utilizator pot interacționa cu nucleul sistemului de operare în două moduri În GDI, DirectDraw, Direct D și OpenGL, apelurile în modul utilizator trec prin biblioteca gdi dll, care oferă o interfață pentru sute de funcții de sistem Pentru a interacționa cu driverele de porturi video și driverele media, apelurile în modul utilizator folosesc API-ul I/O de fișiere obișnuit furnizat în serviciul Windows de bază Apelurile către funcțiile sistemului I/O de fișiere sunt gestionate de managerul I/O al executivului în modul kernel, care apelează driverele corespunzătoare Apelurile GDI, DirectDraw, Direct D și OpenGL trec prin motorul grafic, care le transmite anumitor drivere de dispozitiv Modulele sistemului de operare includ ntoskrnl exe (transfer funcții de sistem, manager I/O), win k sys (motor grafic), mcdsvr dll (server MCD) și hal dll (HAL) Partea executabilă a nucleului Windows NT/ , ntoskrnl exe, este cea mai importantă componentă a nucleului OS Într-un sistem grafic, acesta este în primul rând responsabil pentru transmiterea apelurilor de funcții ale sistemului grafic către motorul grafic, deoarece acesta din urmă utilizează același mecanism de apel de sistem ca și alte funcții de sistem HAL oferă mijloace pentru driverul dispozitivului grafic pentru a efectua operațiuni precum citirea și scrierea registrelor hardware Acest lucru face ca celelalte componente ale nucleului să fie mai puțin dependente de platformă Consultați Capitolul pentru mai multe informații despre partea de execuție și HAL Drivere pentru modul Kernel Sistemul grafic și multimedia Windows NT/ funcționează cu dispozitivele finale prin mai multe straturi de drivere furnizate de producătorul hardware Cel mai important rol îl joacă driverul de ecran, care trebuie să ofere suport pentru GDI, DirectDraw, Direct D și MCD pentru OpenGL Driverul de afișare funcționează întotdeauna împreună cu mini-driverul portului video, care controlează în special porturile hardware Un mini driver pentru portul video este, de asemenea, necesar pentru a suporta VPE (extensia portului video pentru DirectX) și portul mini DxApi Un alt tip de driver mai puțin cunoscut este driverul de font, care furnizează glife de font motorului grafic De exemplu, programul ATM (Adobe Type Manager) folosește biblioteca atmfd dll ca driver de font Fișierele cu fonturi sunt încărcate în spațiul de adrese kernel de către motorul grafic și driverele de font Un driver de imprimantă este similar cu un driver de afișare, cu câteva caracteristici suplimentare Spre deosebire de alte drivere, driverele de imprimantă nu comunică direct cu dispozitivul lor (adică imprimanta) În schimb, ei transmit un flux de date pregătite pentru imprimare către spooler în interfața cu utilizatorul Arhitectura GDI modul Spooler-ul transmite date procesorului de imprimare și apoi monitorului de imprimare, care folosește facilități I/O pentru fișiere pentru a accesa driverul I/O în modul kernel Windows vă permite să implementați un driver de imprimantă atât ca DLL în mod utilizator, cât și ca DLL în mod kernel Alte drivere în modul kernel utilizate de sistemele grafice și multimedia includ drivere pentru dispozitive multimedia (de exemplu, un driver pentru o placă de sunet) și drivere pentru dispozitivul de intrare a imaginilor statice (driver pentru scaner sau cameră digitală) Driverele de streaming kernel (audio, video, captură video) și driverele dispozitivului de intrare a imaginilor statice sunt detaliate în Windows DDK Calitatea driverelor de dispozitiv în modul kernel este esențială pentru stabilitatea întregului sistem de operare Un driver în modul kernel are acces de citire și scriere la întregul spațiu de adrese ale nucleului și la toate instrucțiunile procesorului cu privilegii Erorile din driverul în modul kernel pot deteriora cu ușurință structurile de date importante suportate de sistemul de operare și pot prăbuși întregul sistem Prin urmare, orice aplicație care conține drivere în modul kernel (cum ar fi software-ul antivirus) ar trebui testată cu atenție pentru a reduce riscul Microsoft a inclus un utilitar de verificare a driverului (verifier exe în directorul de sistem) cu Windows care simplifică procesul de verificare a driverului pentru dezvoltatori Această secțiune a descris arhitectura sistemelor grafice și media Windows NT/ , o ierarhie complexă, dar bine structurată de DLL-uri, drivere pentru modul utilizator, DLL-uri pentru modul kernel și drivere pentru modul kernel Este mult mai dificil de înțeles logica funcționării sale - de exemplu, în timpul tipăririi, controlul este transferat de mai multe ori între codul modului utilizator și codul modului kernel Consultați MSDN, DDK și alte documentații de referință pentru detalii, iar accentul nostru se va concentra pe câteva componente care sunt utilizate în cele mai comune aplicații Windows În secțiunile rămase ale acestui capitol, ne vom uita la modul în care funcționează GDI, DirectDraw, driverul de ecran și sistemul de imprimare, inclusiv driverul de imprimantă Arhitectura GDI Interfața aplicației GDI (Graphics Device Interface) a fost dezvoltată de Microsoft pentru a oferi programelor de aplicație o interfață independentă de hardware dispozitivelor grafice, cum ar fi un monitor, o imprimantă, un plotter sau un fax Implementarea Win API a GDI suportată în Windows , , NT și este cu mult înaintea implementării în Windows Sistemele de operare Windows NT/ au un motor grafic complet pe de biți, astfel încât API-ul GDI pe aceste sisteme este mai puternic decât Windows / , care utilizează motorul grafic pe biți moștenit de la Windows Cu toate acestea, există Capitolul Arhitectura grafică Windows și excepții: Windows acceptă ICM, dar Windows NT nu Noul sistem Windows acceptă ICM versiunea Windows a adăugat chiar și noi funcții la GDI, cum ar fi suprapunerea alfa Microsoft intenționează să lanseze o nouă extensie Win GDI, cu nume de cod GDI+, care oferă o interfață îmbunătățită orientată pe obiecte pentru sistemul grafic și este mult mai puternică Funcții exportate din GDI DLL GDI acceptă sute de funcții grafice numite de programele Windows Cele mai multe dintre aceste funcții sunt exportate de biblioteca gdi dll a subsistemului Win Modulul de ferestre, user dll, folosește intens funcțiile GDI pentru a afișa meniuri, pictograme, bare de defilare și chenarele ferestrelor Unele funcții grafice sunt exportate din user dll, făcându-le disponibile pentru programele de aplicație Pe Windows , gdi dll exportă de puncte de intrare Pentru a vizualiza funcțiile exportate de modul, cel mai simplu mod este să utilizați utilitarul dumpbin inclus în distribuția DevStudio Următorul este un fragment din rezultatul comenzii dumpbin gdi dll/export număr de funcții număr de nume indiciu ordinal nume RVA O B AbortDoc У AbortPath FE B AddFontMemResourceEx CE D AddFontResourceA FCCC AddFontResourceExA AddFontResourceExw FE F AddFontResourceTracklng AddFontResourceW DE AngleArc WidenPath B C XFORMOBJ bApplyXForm F FE XFORMOBJJGetXform A XLATEOBJ cGetPalette AB XLATEOBJJiGetColorTransform AA XLATEOBJJXtardiv A BD A XLATEOBJ piVector B F blnitSystemAndFontDirectoriesW C B bMakePathNameW D AA cGetTFFromFOT E A F gdiPlaySpoolStream Grupuri de funcții GDI Cu atât de multe funcții, trebuie să clasificați cumva API-ul Win GDI pentru a înțelege structura GDL MSDN împarte funcțiile API-ului GDI în grupuri care oferă o idee bună despre funcționalitatea GDI Arhitectura GDI Despre Rasters Funcții pentru crearea și afișarea hărților de biți dependente de dispozitiv (DDB, hărți de biți dependente de dispozitiv), hărți de biți independente de dispozitiv (DIB, hărți de biți independente de dispozitiv), secțiuni DIB, pixeli și umpleri Oh, perii Funcții pentru crearea și modificarea obiectelor pensulă în GDL O tăietură Funcții care definesc limitele unei zone de ieșire într-un context de dispozitiv O culoare Gestionarea paletelor Despre Coordonate și transformări Funcții pentru lucrul cu moduri de afișare, funcții pentru maparea coordonatelor logice la cele fizice, precum și funcții pentru transformările lumii Despre contextele dispozitivului Funcții pentru crearea contextelor dispozitivului (Device Context, DC), citirea/scrierea atributelor și selectarea obiectelor GDI Despre figuri umplute Funcții de ieșire pentru regiuni închise și perimetrele acestora Despre fonturi și text Funcții pentru instalarea și enumerarea fonturilor în sistem, precum și pentru ieșirea șirurilor de text Despre linii și curbe Funcții de ieșire pentru linii drepte, arce eliptice și curbe Bezier E Metafișiere Funcții pentru construirea și redarea de metafișiere în format Windows sau metafișiere îmbunătățite О Ieșire pe mai multe monitoare Funcții care vă permit să utilizați mai multe monitoare pe un singur computer Aceste funcții sunt exportate din user dll Despre Ieșire grafică Funcții care controlează gestionarea mesajului de redesenare și a zonei ferestrei modificate Unele dintre aceste funcții sunt exportate din user dll E Traiectorii Funcții pentru concatenarea unei secvențe de linii și curbe într-un obiect GDI numit cale și folosind acel obiect în ieșire Oh, Pene Funcții pentru lucrul cu atribute de ieșire de linie E Imprimare și spooler Funcții pentru transmiterea comenzilor de ieșire grafică către dispozitive precum imprimante și plotere și gestionarea acestei clase de sarcini Funcționalitatea spooler este oferită de un spooler Win care conține mai multe DLL-uri de sistem și module modificate de producătorii de hardware Despre dreptunghiuri Funcții pentru lucrul cu structura RECT Exportat din user dll E Regiunile Funcții pentru crearea unui obiect GDI numit regiune dintr-o serie de puncte și efectuarea de operații asupra acestui obiect Pe lângă funcțiile bine documentate incluse în clasificare, GDI include multe alte funcții puțin cunoscute Unele sunt documentate în DDK; altele nu sunt documentate, dar utilizate de DLL-urile de sistem; altele nu sunt documentate sau utilizate Următoarea este o clasificare aproximativă a unor astfel de funcții E Driver de imprimantă în modul utilizator Funcții de suport pentru o nouă caracteristică în Windows , drivere de imprimantă în modul utilizator Capitolul Arhitectura grafică Windows În esență, acestea sunt funcții de ajutor pentru accesarea punctelor de intrare ale motorului GDI în modul kernel documentate în DDK De exemplu, un driver de imprimantă în modul utilizator Windows poate apela funcția EngTextOut GDI, care este implementată de funcția win k sys cu același nume Despre OpenGL Funcțiile de asistență WGL, cum ar fi SwapBuffers, SetPixelFormat și GetPixelFormat sunt descrise în documentația OpenGL pentru Windows Despre EUDC Funcții de suport pentru caractere definite de utilizator (caractere definite de utilizatorul final); aceste funcții permit utilizatorilor să adauge noi caractere fonturilor Caracteristicile EUDC sunt documentate în secțiunea International Features Platform SDK, sub categoria Window Base Services GDI exportă funcții precum EnableEUDC, EudcLoadLinkW etc О Suport pentru alte DLL-uri de sistem Funcții utilizate numai de alte DLL-uri de sistem De exemplu, user dll apelează funcțiile GDI GdiDllInițiali ze, GdiPrinterThunk, GdiProcessSetup și așa mai departe; ddraw dll apelează GdiEntryl, GdiEntry etc ; serviciul spooler spoolsrv exe apelează GdiGetSpoolMessage și Gdi InitSpool; wow dll apelează GdiQueryTable și GdiCleanCacheDC O Alte caracteristici nedocumentate Funcții nedocumentate care nu sunt cunoscute a fi utilizate, cum ar fi GdiConvertDC, Gdi Con-svertBitmap, SetRelAbs etc Figura ilustrează înțelegerea noastră a arhitecturii client GDI Nivelul superior corespunde categoriilor de caracteristici (documentate sau nedocumentate); sub el sunt sute de funcții împărțite în grupuri majore La nivelul de jos sunt apeluri la funcțiile sistemului Orez Grupuri de funcții GDI Arhitectura GDI Apeluri la funcțiile sistemului GDI În comparație cu DLL-urile diferitelor subsisteme Win , modulul gdi dll este relativ mic Pe Windows , gdi dll are doar kiloocteți, mai mic decât comdlg dll, wow dll, icm dll, advapi dll, user dll și kernel dll Acest lucru se datorează faptului că majoritatea caracteristicilor GDI sunt implementate prin apelarea motorului GDI prin funcțiile sistemului Windows NT/ Microsoft nu furnizează documentație deschisă despre funcțiile sistemului Windows NT/ Deși există utilități care afișează o parte din apelurile de sistem (Numega SoftICE/W), precum și documentație independentă (un articol de Mark Russinovich la www sysinternals com/ntdll htm), nu există documente oficiale despre funcțiile sistemului al sistemului grafic sau al managementului ferestrelor, sau prin funcțiile sistemului suportate de motorul grafic Folosind fișierele cu simboluri de depanare și API-ul Image Help, este ușor să scrieți un program pentru a enumera toate numele simbolice dintr-un DLL, de exemplu, în gdi dll Aceste nume simbolice vor include numele funcțiilor exportate, numele funcțiilor importate și chiar numele variabilelor globale API-ul Image Help include funcția SymEnumerateSymbols, care vă permite să apelați o funcție indirectă de apel invers definită de utilizator pentru fiecare nume simbolic dintr-un modul Cunoscând numele simbolic, puteți determina adresa acestuia în imaginea modulului și puteți citi codul binar pornind de la această adresă Comparând acest cod cu modelul de apelare a funcției de sistem, puteți găsi toate funcțiile GDI din care sunt apelate funcțiile sistemului Programul SysCall face toate cele de mai sus și listează toate funcțiile care utilizează funcțiile sistemului DLL subsistemului Win Puteți afișa informații despre apelurile de funcții ale sistemului de la user dll, ntdll dll sau gdi dll Mai jos este un fragment dintr-o listă de (pentru Windows ) apeluri de funcții de sistem de la gdi dll, sortate după indecșii funcției de sistem syscall( x ) syscall( x ) syscall( x ) syscall( x ) syscall( x ) syscall( x ) syscall( x ) syscall( x ) syscall( x ) x , ) syscall( x ) syscall( x ) syscall( x ) syscall( x ) syscall( x a ) syscall( xlle ) syscall( x ) syscall( x ) syscall( x ) x , ) gd dll!NtGd AbortDoc gdi dll!NtGdiAbortPath gdl dll!NtGdi AddFontResourceW gdi dll!NtGdi AddRemoteFontToDC gdi dll!NtGdi AddFontMemResourceEx gdi dll!NtGdi RemoveMergeFont gdi dll!NtGdiAddRemoteMMInstance BNtGdi dll! gdi dll!NtGd AngleArc gdi dll! NtGdi TransparentBlt gdi dll! NtGdi UnioadPri nterDri ver gdi dll! NtGdi EngCreateBi tmap gdi dll!NtGdi EngCreateDevi ceSurface Capitolul Arhitectura grafică Windows syscall( x , ) gdi dl !NtGdiEngCreateDevIseBitmap syscall( x , ) gdi dll!NtGdiEngCreatePalette syscall( x , ) gdi dll!NtGdiEngCheckAbort syscal ( x ) gdi dl !NtGdi HT Get BPPFormatPalette S-au găsit sisteme totale Lista conține indexul funcției de sistem apelate, numărul de parametri trecuți și numele modulului și funcției din care se efectuează apelul Programul SysCall afișează, de asemenea, adrese de funcții care nu sunt listate aici pentru a economisi spațiu Partea centrală a programului SysCall este clasa KlmageModule Funcționarea acestei clase se bazează pe utilizarea Win Image Help API, o interfață concepută pentru a procesa imaginile descărcate ale fișierelor executabile Win Clasa încarcă și descarcă module cu fișiere de simboluri de depanare, convertește între nume și adrese și enumerează numele simbolurilor Lista apelurilor de funcții de sistem este implementată prin listarea tuturor numelor simbolice din modul și verificând cu modelul standard de apeluri ale funcției de sistem De la Win GDI API la GDI Engine System Functions Comparând cele două liste (funcții exportate de GDI și funcții de sistem numite de la GDI ), nu este greu de ghicit sau cel puțin de a face o presupunere educată cu privire la modul în care funcțiile GDI Win se mapează la funcțiile sistemului win k sys De exemplu, funcția de imprimare AbortDoc ar apela cu siguranță NtGdiAbortDoc, funcția de sistem la indexul x ; Funcția de suport pentru driverul de imprimantă în modul utilizator, EngBitBlt este un alias simplu pentru NtGdiEngBitBlt, deoarece ambele funcții au aceeași adresă Unele funcții API Win există într-o versiune simplă care este mai ușor de utilizat și o versiune avansată care acceptă funcții suplimentare De exemplu, funcțiile AddFontResource și AddFont-ResourceEx formează o astfel de pereche Este logic să presupunem că Microsoft nu creează două apeluri de sistem diferite pentru aceste funcții - doar AddFontResource apelează AddFontRe-sourceEx Funcțiile care preiau parametri șir există de obicei în două versiuni ale API-ului Win : versiunea ANSI se termină cu „A” și versiunea Unicode se termină cu „W” Funcția de sistem NT/ există doar în versiunea Unicode, deoarece codarea de bază a sistemului de operare este Unicode Poate ați observat că cele trei apeluri la Add-FontResourceXXX corespund unei singure funcții de sistem, NtGdiAddFontResourceW Compararea listei de funcții GDI exportate cu lista funcțiilor sistemului GDI arată că unele zone ale funcționalității GDI sunt implementate exclusiv la nivelul utilizatorului clientului GDI, fără apeluri intermediare către motorul GDI Operațiunile meta sunt un bun exemplu Arhitectura DirectX Fișiere Windows și metafișiere extinse, pentru care nu se găsește nicio urmă în lista de apeluri de sistem Același lucru este valabil și pentru funcționalitatea bazată pe utilizarea EMF, cum ar fi EMF ocolind spooler-ul GdiStartDocEMF, GdiStartPageEMF, Gdi-PlayPageEMF etc De asemenea, lipsesc din listă diverse funcții API Win pentru citirea și scrierea atributelor sistemului, cum ar fi GetBkMode, SetText-Coloog și așa mai departe Probabil că cele mai apropiate apeluri de sistem sunt NtGdiGetDCDword și NtGdiGetAndSetDCDword mai generale După cum veți vedea mai târziu, unele atribute de context ale dispozitivului sunt stocate în memoria în modul utilizator pentru a facilita accesul, în timp ce altele sunt stocate într-o structură de date în modul kernel În rezumat, subsistemul Win DLL gdi dll implementează Win GDI în primul rând prin simpla mapare a apelurilor de funcție Win API la apelurile de funcție de sistem implementate de motorul grafic GDI în fișierul win k sys Unele zone (metafile și manipulare îmbunătățită a metafișierului, imprimarea EMF care ocolește spoolerul) sunt caracteristici cu adevărat noi furnizate de gdi dll fără suport direct din partea motorului GDI Bibliotecile client GDI oferă, de asemenea, implementări pentru alte componente ale sistemului - DirectDraw, Direct D, OpenGL, imprimare și spool Arhitectura DirectX Deși performanța și capacitățile API-ului GDI au fost suficiente pentru majoritatea programatorilor de aplicații, Microsoft s-a luptat destul de mult timp pentru a câștiga programatori de jocuri de partea sa În jocuri, în primul rând, este nevoie de grafică rapidă, pentru care API-uri independente de hardware precum Windows GDI sunt complet nepotrivite Microsoft a încercat să implementeze API-ul DrawDIB (parte a Video pentru Windows), WinG (o bibliotecă mică care accelerează randarea bitmap-ului), WinToon (un motor de sprite animat), Game SDK și, în cele din urmă, sa stabilit pe DirectX Interfața DirectX a fost dezvoltată de Microsoft pentru programarea unei noi generații de jocuri pe calculator și aplicații multimedia cu grafică intensivă DirectX include și interfața DDI (Device Driver Interface), care definește capacitățile care trebuie implementate în driverele de afișare furnizate de producătorul hardware Astfel, DirectX se concentrează pe două obiective importante La nivel de interfață, DirectX oferă dezvoltatorilor de jocuri/aplicații un API puternic, independent de hardware, fără a compromite performanța Programatorii de aplicații pot folosi noile funcții ale dispozitivului fără a-și face griji să lucreze direct cu hardware-ul La nivel de driver de dispozitiv, DirectX permite producătorilor de hardware să se concentreze pe inovațiile hardware și să le aducă cu ușurință pe piață printr-un strat subțire de drivere Game SDK este prima versiune a DirectX, iar schimbarea numelui a fost din motive de marketing - Notă transl Capitolul Arhitectura grafică Windows cu suport DirectX Interfața DirectX DDI oferă producătorilor de hardware îndrumarea necesară care poate fi integrată cu ușurință în DirectX Componente DirectX DirectX constă din mai multe componente principale legate de diverse domenii ale programării jocurilor și multimedia Direct include în prezent următoarele componente Despre DirectDraw este o interfață grafică D rapidă care acceptă acces direct la memorie video, blitting rapid (transfer de bloc de biți), comutare buffer-ul înapoi și buffer, controlul paletei, tăierea, suprapunerile și tastele de culoare DirectDraw poate fi considerat ca un subset de GDI conceput special pentru redarea rapidă a graficelor Despre DirectSound - înregistrare și redare accelerată a sunetului digitizat (eșantioane digitale) cu amestecare cu latență scăzută și acces direct la dispozitivele de sunet Despre DirectMusic - Convertește datele muzicale generate în loturi în mostre digitizate folosind un sintetizator hardware sau software Mostrele digitizate sunt apoi transmise în flux la DirectSound ca date de streaming audio Despre DirectPlay - Simplificați interacțiunea modemului sau a rețelei dintre jucători în jocurile multiplayer DirectPlay oferă o modalitate universală de comunicare între aplicațiile DirectX, independent de protocolul, transportul sau serviciul de rețea utilizat Despre Direct D oferă două niveluri de API pentru lucrul cu grafica tridimensională în jocuri - modul imediat (Mod Imediat) și modul abstract (Mod Reținut) Direct D Direct Mode este un API de grafică D de nivel scăzut, care este ideal pentru programatorii experimentați care port jocurile și aplicațiile multimedia existente în DirectX Modul abstract Direct D este un API de nivel înalt care facilitează implementarea aplicațiilor grafice D; se bazează pe utilizarea modului imediat Direct D Direct D acceptă un tampon de adâncime comutabil, umbrire uniformă și umbrire gouraud, luminând scena cu mai multe tipuri diferite de lumini, precum și lucrul cu materiale și texturi, transformări și tăiere Modul abstract Direct D este întrerupt în prezent și va fi înlocuit cu o nouă tehnologie în viitor Un DirectInput oferă suport pentru dispozitive interactive de intrare, cum ar fi mouse-uri, tastaturi, joystick-uri, dispozitive de feedback și alte controlere de joc Despre DirectSetup - un API simplu pentru instalarea componentelor DirectX Aplicațiile de jocuri și multimedia folosesc adesea modul Autoplay, Arhitectura DirectX în care programul de instalare sau jocul este lansat automat când este introdus CD-ul Despre DirectShow - Redați conținut audio și video comprimat într-o varietate de formate, inclusiv MPEG, QuickTime, AVI și WAV Este posibil să adăugați noi formate prin conectarea unor module noi numite filtre; sunt gestionate de DirectShow Filter Manager Despre DirectAnimation oferă efecte de animație într-o varietate de medii, inclusiv HTML, VBScript, JScript, Java și Visual C++ Grafica vectorială și raster, sprites, forme geometrice tridimensionale, video și sunet sunt combinate într-o interfață de animație API DirectAnimation conține, de asemenea, câteva elemente client Media Player ale căror proprietăți și metode sunt concepute pentru a controla redarea media pe o pagină web sau aplicație Pe fig Figura prezintă o arhitectură DirectX care a fost îndepărtată de unele componente mici pentru a economisi spațiu La nivelul de jos, DirectX apelează GDI pentru a apela funcțiile sistemului Pe baza acestor funcții de sistem, sunt construite modurile DirectDraw, DirectSound, DirectMusic, Direct D direct și abstract Funcționalitatea tuturor acestor componente este asigurată printr-un set de interfețe COM DirectShow și DirectAnimation sunt construite pe deasupra acestor componente DirectX de bază și se bazează, de asemenea, pe diferite filtre pentru a funcționa La nivelul superior se află jocurile, aplicațiile multimedia, applet-urile Java, paginile web și așa mai departe Fiecare componentă DirectX este reprezentată de unul sau mai multe DLL-uri subsistem Win cu nume ușor de recunoscut De exemplu, ddraw dll și ddrawex dll implementează API-ul DirectDraw; d dim dll implementează API-ul mod direct Direct D; d drm dll implementează API-ul modului abstract Direct D Spre deosebire de API-ul Win tradițional, care constă din sute de funcții, API-ul DirectX este accesat prin interfețele COM (Component Object Model) O interfață COM este un grup de funcții legate semantic cu tipuri predefinite de parametri și valori returnate În paradigma de programare C, o interfață COM poate fi gândită ca un tabel de funcții; în lumea C++, o interfață COM este analogă cu o clasă de bază abstractă Interfețele COM sunt implementate de clase COM Dar, deoarece filosofia COM este de a menține implementarea distinctă de interfață, programele client pot crea doar instanțe ale claselor COM (numite și obiecte COM) și pot efectua operațiuni asupra lor prin interfețe COM După publicare, interfața COM este „înghețată” Aceasta înseamnă că definiția unei interfețe nu poate fi modificată, deși implementarea acesteia poate fi schimbată în mod liber Pentru a oferi unei aplicații funcții noi, există o singură modalitate - de a proiecta și publica noi interfețe Din acest motiv, există interfețe numite IDirectDraw, IDirectDraw și IDirectDraw Pe fig arată doar o parte din interfețele COM suportate de unele componente DirectX Majoritatea componentelor DirectX definesc prea multe interfețe pentru a se potrivi într-un desen Capitolul Arhitectura grafică Windows Jocuri DirectX, aplicații multimedia, applet-uri Java, pagini HTML etc Pluginuri de browser Elemente client DirectAnimation Elemente Media Ployer DirectAnimation (danim dll) Manager de filtre DirectShow Filtru sursă Filtru de transformare Filtru de reluare DirectDraw | IDirectDrawSurface | IDirectDrawPalette | IDirectDrawClipper | IDirectDrawVideoPort | IDirectSound | iDirectSoundBuffer | â D CD co •O o b IDirectSoundCapture | o E, IDirectMusic IDirectMusicLoader IDirectMusicCollection IDirectMusicComposer | o E, w Q w oo | IDirect DDevice | IDirect DExecuteBuffer I IDirect DLight o E, co Z o: co ■s | IDirect DRMDevice O) □ Z o: co o IDirect DRMMateria o E, DirectDraw (ddraw dll, ddrawex dll) DirectSound (dsound dll) DirectMusic (dmusic dll) Direct D Direct Mode (d dim dll) Direct D Abstract Mode (d dim dll) GDI și alte servicii OS Orez Arhitectura de bază a DirectX Arhitectura DirectDraw Subiectul principal al acestei cărți este programarea grafică D pe Windows - cu alte cuvinte, GDI și DirectDraw Informații despre restul componentelor DirectX pot fi adunate din documentația MSDN, din alte cărți și resurse de pe Internet și vom trece la o privire asupra arhitecturii DirectDraw DirectDraw poate fi gândit ca o versiune specializată a GDI Prima etapă de specializare este că ieșirea este direcționată numai către adaptorul video și nu către o imprimantă, plotter sau orice alt dispozitiv grafic existent A doua etapă este reducerea funcționalității suportate de GDI DirectDraw nu acceptă direct modurile de afișare, transformările lumii, fonturile și textul, liniile și curbele; munca se efectuează numai cu imagini raster Ultima etapă este implementarea unui subset limitat, ținând cont de accelerarea hardware și adăugând caracteristici importante pentru jocuri și programare multimedia DirectDraw implementează șapte interfețe majore, dintre care două există în mai multe versiuni Arhitectura DirectX Despre IDirectDraw este interfața de bază DirectDraw din care pot fi derivate alte obiecte DirectDraw Cea mai recentă versiune este IDirectDraw? Interfețele IDirectDraw asigură crearea altor obiecte DirectDraw, gestionarea suprafețelor, alegerea rezoluției și adâncimea culorii, obținerea de informații despre starea ecranului, alocarea memoriei și așa mai departe Apelarea Direct-DrawCreate creează un obiect DirectDraw care acceptă diverse interfețe IDirectDraw A Interfața IDirectDrawSurface oferă toate operațiunile de ieșire din DirectDraw Cea mai recentă versiune este IDirectDrawSurface? Această interfață include operațiuni cu suprafețe - obținerea de informații despre capabilități, blocare și deblocare, alegerea unei palete, tăiere etc Când o suprafață este blocată, memoria adaptorului video este mapată la spațiul de adrese virtuale al aplicației, ceea ce permite organizarea acces direct la acesta, asociind un context de dispozitiv GDI cu o suprafață DirectDraw și ieșire către suprafețe folosind GDI Mai important, IDirectDrawSurface acceptă blitting între suprafețe și comutarea suprafețelor accelerată de hardware Pentru a efectua operațiuni mai complexe, va trebui fie să le implementați singur, fie să apelați la GDI A Interfața IDirectDrawPalette acceptă crearea și manipularea directă a unei palete de culori pe un ecran de de culori A Interfața IDirectDrawClipper gestionează tăierea suprafețelor DirectDraw folosind liste de clipuri, reprezentate de structurile API GDI RGNDATA Deoarece DirectDraw nu acceptă cliplisting, aveți în continuare o gamă bogată de operațiuni regionale disponibile în GDI A Interfața IDirectDrawColorControl controlează culoarea suprafețelor și a suprapunerilor ajustând luminozitatea, contrastul, nuanța, saturația și gama A Interfața IDirectDrawGammaControl controlează procesul de corecție gamma, care convertește valorile culorii din buffer-ul de cadre în culori care sunt transmise convertorului hardware digital-analog (DAC) A Interfața IDirectDrawVideoPort oferă transfer de date video de la un port video hardware pe o suprafață DirectDraw Cu acesta, programatorul poate controla echipamentul prin portul video Pe fig Figura prezintă arhitectura DirectDraw cu componente atât în modul utilizator, cât și în modul kernel Componenta în modul utilizator a DirectDraw este biblioteca ddraw dll, care este asociată cu gdi dll și mcd dll (OpenGL) Apelurile la funcțiile DirectDraw trec prin gdi dll și au ca rezultat apeluri la funcții de sistem care sunt preprocesate de managerul de funcții de sistem în spațiul de adrese din modul kernel Dispecerul transmite apelul motorului grafic (win k sys), după care apelul este transmis fie driverului de afișare furnizat de producătorul hardware, fie driverului portului video DirectDraw nu este un înlocuitor clar pentru GDI din cauza concentrării sale pe ecranul și funcționalitatea limitată Capitolul Arhitectura grafică Windows poate forța aplicațiile DirectDraw să utilizeze suportul GDI, în special atunci când desenează curbe, operațiuni cu regiuni, fonturi și text O înțelegere profundă a implementării GDI vă va ajuta, de asemenea, să simulați GDI cu DirectDraw Manager funcții de sistem (ntoskrnl exe) Motor grafic (win k sys) Driver pentru portul video Driver pentru ecran (DirectDraw HAL) Orez Arhitectura DirectDraw În documentația Microsoft și în alte documente, DirectDraw este adesea descris alături de GDI, ambele interfețe lucrând direct cu hardware-ul printr-un strat de abstractizare dependent de hardware Unele cărți susțin chiar că nu veți avea nevoie de GDI atunci când lucrați cu DirectDraw De fapt, API-ul DirectDraw este implementat de biblioteca ddraw dll, a cărei interacțiune cu motorul grafic și apoi cu driverele de dispozitiv este asigurată de gdi dll Biblioteca ddraw dll importă o serie de funcții importante nedocumentate exportate de GDI, aproape totul, de la Gdi Entryl la Gdi Entryl În secțiunea Windows Graphics System Components, a fost menționat programul SysCall, care este conceput pentru a afișa o listă de funcții de sistem numite într-un DLL de sistem (de exemplu, gdi dll) Dacă vă uitați la această listă pentru GDI , veți găsi zeci de apeluri la funcțiile sistemului DirectDraw și Direct D, cum ar fi NtGdiDdCreateSurface, NtGdiD dTexture-Swap și NtGdoD dDrawPrimitives Desigur, aceste funcții nu sunt utilizate în interfața GDI în sine Singura explicație posibilă este că GDI exportă aceste funcții către interfețele DirectDraw/Direct D pentru ddraw dll și alte DLL-uri DirectX prin puncte de intrare nedocumentate Implementarea DirectDraw constă din mai multe straturi Nivelul superior acceptă interfețe DirectDraw COM, funcții standard exportate Arhitectura sistemului de imprimare Obiecte COM (DIIGetClassObject, etc ) și funcții speciale pentru crearea obiectelor DirectDraw (DirectDrawCreate, etc ) Stratul de mijloc, HEL (Hardware Emulation Layer), emulează toate sau unele dintre caracteristicile DirectDraw neacceptate de hardware Stratul inferior, numit HAL (Hardware Abstraction Layer), interacționează direct cu adaptorul video Dar ce DLL-uri implementează DirectDraw HEL și DirectDraw HAL? Se pare că DirectDraw HEL este o parte importantă a ddraw dll, un DLL în modul utilizator pe de biți Acest lucru poate fi verificat în mai multe moduri Mai întâi, aruncați o privire la dimensiunea lui ddraw dll - KB, puțin mai mare decât gdi dll Din aceasta putem concluziona că ddraw dll este ceva mai mult decât un strat API subțire Apoi uită-te la lista de importuri ddraw; veți găsi în el funcții GDI precum CreateDIBSection, StretchDIBits, PatBlt, BitBlt etc Prin urmare, ddraw folosește funcții GDI în procesul de desen În cele din urmă, utilizați un program care listează nume simbolice în fișierele de informații de depanare, cum ar fi depanatorul Visual C++ Veți găsi nume precum HELBlt, HEInitial izeSpecialCases și general-AlphaBlt în ddraw dll Lista conține, de asemenea, destul de multe nume cu prefixul „mmx” care se referă la setul extins de instrucțiuni multimedia al procesoarelor Intel Prin urmare, ddraw dll oferă o optimizare specială DirectDraw HEL pentru MMX Implementarea DirectDraw HEL în modul utilizator simplifică foarte mult utilizarea codului atât în Windows NT/ , cât și în Windows / În plus, utilizarea instrucțiunilor de calcul reale și a instrucțiunilor MMX, care nu sunt bine acceptate de modul kernel al sistemului de operare, este plină de anumite dificultăți Inutil să spun că, cu mai mult cod în modul utilizator, DirectDraw blochează sistemul mai rar DirectDraw HAL este un driver de dispozitiv generic furnizat de producătorul unui adaptor video care acceptă DDI DirectDraw Rețineți că straturile DirectDraw API și HEL în modul utilizator nu au acces direct la stratul DirectDraw HAL, care rulează în modul kernel pe Windows NT/ Pentru a ajunge la DirectDraw HAL, trebuie să parcurgeți funcțiile sistemului GDI gestionate de motorul GDI (win k sys) Această carte va oferi mai multe informații despre DirectDraw Secțiunea „Referire la spațiul de adrese în modul Kernel” din Capitolul explorează structurile de date interne ale DirectDraw Secțiunea „Monitorizarea interfețelor COM DirectDraw” din Capitolul acoperă procesul de monitorizare a interfețelor DirectDraw În cele din urmă, capitolul este dedicat descrierii DirectDraw Arhitectura sistemului de imprimare API-ul Win GDI a fost conceput ca un API independent de hardware, capabil să afișeze linii drepte, curbe, hărți de biți și text pe orice dispozitiv grafic pentru care există un driver adecvat Cu toate acestea, imprimantele constituie o clasă specială de dispozitive grafice și merită Capitolul Arhitectura grafică Windows atentie speciala Următoarele sunt diferențele cheie dintre imprimante și alte dispozitive grafice A Utilizatorii imprimă, de obicei, un document întreg, mai degrabă decât o singură pagină, setând opțiuni specifice, cum ar fi calitatea imprimării, dimensiunea hârtiei, modul duplex, numărul de copii etc GDI conține o imprimantă API dedicată pentru imprimarea pagină cu pagină, precum și a DEVMODE toate opțiunile de imprimare Aspecte precum paginarea documentului și selectarea dimensiunilor marginilor sunt sub controlul aplicației A O imprimantă are de obicei o rezoluție mult mai mare ( până la dpi) decât un ecran de monitor ( până la dpi) Acest lucru duce la o creștere a cantității de date procesate și la o posibilă lipsă de memorie pentru a reda simultan întreaga pagină Mecanismul GDI permite driverului de imprimantă să primească date în bucăți mici (stripe) prin spooling EMF (metafișier extins) A Imprimanta este de obicei lentă, partajată de mai mulți membri ai grupului de lucru și nu se conectează întotdeauna la computerul local Spooler-ul de sistem Windows asigură că aplicațiile își finalizează rezultatele cât mai devreme posibil, că imprimanta poate servi mai multe lucrări de imprimare și că grupuri de utilizatori partajează imprimanta local, printr-o rețea și chiar printr-o adresă URL A Imprimantele „vorbesc” diferite limbi - PCL (imprimante HP), ESC/P (imprimante Epson), PostScript (imprimante compatibile PostScript) și HPGL (plotere) În această privință, ele sunt fundamental diferite de adaptoarele video care funcționează cu bitmaps Microsoft oferă mai multe drivere „universale” care pot fi personalizate de producătorii de hardware pentru a îndeplini cerințele specifice ale dispozitivelor lor Elementul central al arhitecturii de imprimare Windows NT/ este spoolerul de imprimare acceptat de GDI și driverul de imprimantă Pentru a crea o nouă lucrare de imprimare, aplicația utilizator accesează punctele de intrare API exportate de GDI și DLL-ul client spooler GDI și spooler-ul (prin driverul de imprimantă) procesează lucrarea de imprimare și trimit datele către dispozitivul de copiere pe hârtie, fie că este o imprimantă laser, o imprimantă cu jet de cerneală, un plotter sau un fax Comenzile grafice sunt transmise la GDI ca apeluri API GDI, care sunt de obicei stocate într-un metafișier îmbunătățit (EMF) EMF și un alt fișier cu setările curente de imprimare sunt transmise procesului de serviciu spooler de sistem (spools exe) În această etapă, tipărirea documentului la nivel de aplicație este finalizată Utilizatorul poate continua să lucreze cu aplicația, iar imprimarea ulterioară a documentului va fi efectuată de către spooler Spooler-ul direcționează mai întâi lucrarea către furnizorul de imprimare care deservește imprimanta respectivă Imprimantele locale sunt deservite de furnizorul local de imprimare (localspl dll), iar imprimantele de rețea sunt deservite de furnizorul de imprimare în rețea Windows (win spl dll) Dacă imprimanta este conectată la un computer la distanță, atunci fișierele spooler sunt trimise către computerul de la distanță de către serviciile de rețea OS, unde sunt trimise la spooler ca o lucrare pentru computerul local Figura ilustrează arhitectura sistemului de imprimare în Windows NT/ Arhitectura sistemului de imprimare Sistem local WinNT/ Server WinNT/ Aplicație aproximativ £ DLL pentru interfața driverului de imprimare RPC Serviciu de spool (spoolsv dll) Router Spooler (spoolsv dll) Furnizor de imprimare pentru rețele Windows (win spl dll) MÂNCA GDI (gdi dll) Furnizor local de imprimare (localspl dll) Procesor de imprimare (localspl dll) Router Spooler (spoolsv dll) Serviciu de spool (spoolsv dll) Driver de imprimantă în modul utilizator Monitor de limbă DLL pentru interfața driverului de imprimare Port Monitor Modul utilizator Modul Kernel File I/O' Funcțiile sistemului Manager I/O motor grafic Driver de font Modul Kernel Driver de imprimantă Drivere de rețea Drivere pentru portul de imprimantă Fonturi Orez Arhitectura sistemului de imprimare în Windows NT/ Când furnizorul local de imprimare primește în sfârșit lucrarea, aceasta este transmisă procesorului de imprimare Procesorul de imprimare verifică formatul fișierului spooler Pentru fișierele EMF, fiecare pagină este redată în GDI Ca rezultat, comenzile GDI sunt defalcate în primitive grafice definite în interfața DDI, care sunt apoi transmise driverului de imprimantă Driverul de imprimantă convertește elementele grafice primitive în date de limbaj de imprimantă de nivel scăzut, cum ar fi PCL, ESC/P sau PostScript Datele de nivel scăzut sunt returnate procesorului de imprimare Când procesorul de imprimare primește date de nivel scăzut gata pentru a fi trimise către imprimantă, le transmite monitorului de limbă Monitorul de limbă trimite date către monitorul de porturi, care utilizează API-ul sistemului de fișiere pentru a scrie date în portul hardware Funcționarea codului încorporat (firmware) pe partea imprimantei nu ne interesează; credem că, ca urmare a lanțului lung de componente software descrise mai sus, documentul dumneavoastră se va tipări cu succes Să aruncăm o privire mai atentă asupra componentelor sistemului de imprimare Windows NT/ Capitolul Arhitectura grafică Windows Client spooler Win Win Spooler Client DLL (winspool drv) oferă aplicațiilor utilizatorului acces la API-ul spooler Aplicația utilizator folosește API-ul spooler pentru a interoga imprimantele și lucrările de imprimare, pentru a obține și determina setările imprimantei, pentru a încărca o interfață DLL a driverului de imprimantă pentru a afișa o casetă de dialog cu setări de imprimare și așa mai departe De exemplu, sunt incluse funcțiile OpenPrinter, WritePrinter și ClosePrinter în spoolerul API poate fi folosit pentru a trimite date direct la imprimantă, ocolind ieșirea standard prin GDI și driverul de imprimantă API-ul spooler este definit în fișierul antet winspool h, iar fișierul său de bibliotecă este winspool lib Astfel, winspool drv este încărcat în procesul de aplicare atunci când trebuie să se imprime DLL-ul client spooler ajută GDI să determine modul în care ar trebui să fie procesată jobul Pentru joburile obișnuite, GDI generează un fișier EMF și îl transmite clientului spooler, care utilizează mecanismul RPC pentru a transmite job-ul procesului sistemului de serviciu spooler Serviciul Spooler Spooler-ul Windows NT/ este implementat ca un serviciu, un proces care are privilegii speciale și responsabilități speciale în sistem Serviciul spooler pornește când sistemul de operare pornește Din acest motiv, imprimanta începe uneori să imprime automat când sistemul este repornit, dacă au existat lucrări de imprimare neprocesate în sistem când lucrarea a fost oprită Comanda net stop spooler oprește procesul spooler, iar comanda net start spooler îl repornește După oprirea spoolerului, widgetul Imprimante din Panoul de control nu mai funcționează Serviciul spooler exportă o interfață bazată pe RPC (Remote Procedure Caii) către DLL-ul client spooler, care este utilizată de aplicație pentru a gestiona imprimantele, driverele de imprimantă și lucrările de imprimare Serviciul spooler în sine este un fișier EXE mic (spoolsv exe) Majoritatea apelurilor sale de funcții sunt transmise furnizorului de imprimare prin routerul spooler Serviciul spooler este o componentă a sistemului care nu poate fi înlocuită Router Spooler Imprimanta la care imprimați nu este întotdeauna conectată la computerul dvs — poate fi undeva în rețeaua Microsoft, pe un server Novell sau oriunde altundeva în lume (caz în care se tipărește la o adresă URL) Folosind DLL-ul routerului (spoolss dll), serviciul spooler transmite lucrările de imprimare unui furnizor care știe unde să trimită lucrarea În ceea ce privește compoziția funcțiilor exportate, biblioteca spoolss dll seamănă cu winspool drv De exemplu, se întâlnesc funcțiile AddPrinter, OpenPrinter, EnumJobW etc Arhitectura sistemului de imprimare sunt disponibile în ambele biblioteci În timpul spooling-ului, apelurile sunt adesea trecute de la un modul la altul, apoi la un al treilea și așa mai departe, până când ajung la destinație Funcția principală a routerului este simplă - să găsești furnizorul de imprimare potrivit și apoi să trimiți informații Căutarea este efectuată de numele sau manipulatorul (mânerul) imprimantei utilizând setările imprimantei din registrul de sistem Când o aplicație utilizator efectuează un apel OpenPrinter către DLL-ul client spooler (winspool drv), acel apel este transmis serviciului de sistem spooler (spoolsv exe) Acesta din urmă apelează routerul spooler, care apelează funcția OpenPrinter a fiecărui furnizor de imprimare până când unul dintre ei returnează un handle care indică faptul că furnizorul de imprimare a recunoscut numele imprimantei Acest handle este returnat aplicației, astfel încât apelurile ulterioare să fie imediat direcționate către furnizorul de imprimare corect Routerul spooler este o componentă a sistemului care nu poate fi înlocuită Furnizor de imprimare Furnizorul de imprimare este responsabil pentru trimiterea lucrărilor de imprimare către un computer local sau la distanță De asemenea, gestionează operațiunile din coada de lucrări de imprimare, cum ar fi pornirea, oprirea și listarea lucrărilor Spre deosebire de un router și un serviciu de spooler, mai mulți furnizori de imprimare pot fi prezenți pe un sistem Producătorii de imprimante își pot crea propriii furnizori de imprimare folosind Windows NT/ DDK Mai mulți furnizori de imprimare sunt incluși în sistemul de operare A Furnizorul local de imprimare (localspl dll) gestionează lucrările de imprimare locale sau lucrările trimise de la clienți la distanță către computerul local În cele din urmă, fiecare lucrare este procesată de furnizorul local de imprimare, care transmite lucrarea procesorului de imprimare În Windows , procesorul de imprimare implicit este implementat în DLL-ul furnizorului local de imprimare Un furnizor de imprimare în rețea Windows (win spl dll) trimite lucrări de imprimare la un server Win la distanță A Furnizorul de imprimare Novell Netware (nwprovau dll) trimite lucrări de imprimare către serverele de imprimare Novell Netware Deoarece fișierele EMF nu sunt procesate de serverele Novell, lucrările de imprimare trebuie convertite în date de nivel scăzut (RAW) înainte de a fi trimise către serverul Novell A Furnizorul de imprimare HTTP (inetpp dll) trimite lucrările de imprimare către adrese URL Toți furnizorii de imprimare trebuie să implementeze un set de funcții obligatorii enumerate în DDK, astfel încât routerul spooler să poată lucra cu ele în conformitate cu aceleași reguli Alte caracteristici sunt optionale Directorul src\print\pp al Windows DDK conține codul sursă pentru un exemplu de furnizor de imprimare Punctul de intrare principal al furnizorului se numește Inițialize-PrintProvider Alte puncte de intrare sunt accesate prin tabelul de funcții returnat de Inițial izePrintProvider Capitolul Arhitectura grafică Windows Furnizorul local de imprimare trebuie să implementeze funcționalitatea completă a furnizorului de imprimare, inclusiv anularea lucrărilor de imprimare, apelarea interfeței driverului de imprimantă DLL și apelarea procesoarelor de imprimare pentru a procesa lucrarea Procesor de imprimare Procesorul de imprimare este responsabil pentru convertirea fișierelor spool ale lucrării de imprimare în date de nivel scăzut care pot fi trimise la imprimantă În plus, aceștia sunt chemați să efectueze operațiuni de control asupra lucrărilor de imprimare - pentru a întrerupe, relua și anula solicitările Procesorul de imprimare este apelat de furnizorul local de imprimare Fișierele spool pentru lucrări de imprimare în Windows NT/ sunt de obicei stocate în format EMF GDI ajută la convertirea aplicației grafice a unei aplicații în format EMF și la scrierea rapidă a fișierului pe disc, astfel încât aplicația să își poată relua funcționarea normală Fișierele spool sunt de obicei stocate în directorul $SystemRoot$\spool\printers Pentru lucrările de imprimare EMF, spooler-ul generează două fișiere Fișierul cu extensia shd conține parametrii jobului - numele imprimantei, numele documentului, numele portului și o copie a structurii DEVMODE Fișierul spl conține un antet nedocumentat, fonturi încorporate și o pagină EMF pentru fiecare pagină de document tipărită Windows este livrat cu două procesoare de imprimare standard: o Procesorul de imprimare Windows (în localspl dll) acceptă diverse formate de spool, inclusiv NT EMF, RAW și TEXT; A Procesorul de imprimare Macintosh (în sfmpsprt dll) acceptă formatul PSCRIPT Formatul EMF este formatul de fișier spool comun pentru toate aplicațiile Windows Un fișier EMF ocupă de obicei mult mai puțin spațiu decât datele de nivel scăzut care sunt gata să fie trimise la o imprimantă Fișierele EMF sunt de obicei generate de GDI cu o intrare minimă din driverul de imprimantă Dacă imprimați printr-o rețea, trimiterea lucrărilor de imprimare EMF are ca rezultat mai puțin trafic de rețea În plus, computerului client îi este permis să continue funcționarea normală în timp ce serverul este ocupat cu conversia EMF în date de imprimantă de nivel scăzut În timpul procesului de construire a fișierului EMF, GDI contactează computerul de la distanță pentru a întreba dacă fonturile sunt disponibile Dacă unele fonturi lipsesc pe computerul de la distanță, acestea sunt încorporate în fișierul shd, trimise la computerul de la distanță și instalate acolo Dacă selectați tipul de date RAW, datele imprimantei vor fi generate pe computerul client în loc de server; acest lucru va avea ca rezultat mai mult trafic de rețea, dar și mai puțină memorie și putere de procesare pe server Un fișier spool PostScript pentru imprimantele compatibile cu PostScript este considerat un fișier RAW deoarece nu necesită o conversie suplimentară înainte de a fi trimis la imprimantă Fișierele spool în format TEXT constau exclusiv din text codificat ANSI Pentru redarea șirurilor de text într-un format acceptat Arhitectura sistemului de imprimare locuiește lângă imprimantă, procesorul de imprimare răspunde Pentru a face acest lucru, face cereri către GDI și driverul de imprimantă Probabil, imprimarea în format TEXT poate fi utilă în aplicațiile DOS Formatul PSCRIPT și procesorul de imprimare sfmpsprt nu sunt proiectate pentru imprimante PostScript Mai degrabă, un fișier PSCRIPT este în format PostScript, dar motorul de imprimare sfmpsprt îl convertește în format RAW pentru a fi scos pe o imprimantă Prin urmare, sfmpsprt este într-adevăr un interpret PostScript Procesorul de imprimare nu are acces direct la fișierele spool, iar formatele acestora nu sunt documentate Procesorul de imprimare folosește serviciile GDI și API ale clientului spooler (winspool drv) pentru a converti fișierele în date de imprimantă de nivel scăzut Alegerea dvs nu se limitează la cele două procesoare de imprimare furnizate de Microsoft Windows NT/ DDK include documentație completă și un exemplu de procesor de imprimare funcțional Directorul src\print\genprint al Windows DDK conține un exemplu de procesor de imprimare pentru formatul EMF Puteți să-l compilați, să copiați binarul în directorul $SystemRoot$\system \spool\prtprocs\w x , să scrieți un mic program care apelează AddPrintProcessor pentru a-l instala și apoi să vă jucați cu propriul procesor de imprimare în depanator Windows NT DDK conține un procesor de imprimare eșantion mai complet, cu suport pentru formatele EMF, RAW și TEXT Principalele puncte de intrare ale procesorului de imprimare sunt funcțiile OpenPrint-Processor, PrintDocumentOnPrinterProcessor și ClosePrintProcessor Funcția OpenPrint-Processor inițializează procesorul de imprimare pentru a accepta o lucrare; PrintDocumentOn-PrinterProcessor procesează lucrarea de imprimare, iar ClosePrintProcessor eliberează memoria alocată în OpenPrintProcessor Pentru fișierele EMF spool, Windows NT GDI are o singură funcție GdiPlayEMF care redă întregul document Windows acceptă un API mai extins, dar încă oarecum limitat, care permite procesorului de imprimare să interogheze pagini individuale ale unui fișier EMF, să schimbe ordinea de redare a paginii, să îmbine mai multe pagini logice într-o singură pagină fizică și să folosească transformări ale coordonatelor mondiale la randarea EMF fișiere De exemplu, în implementarea PrintDocumentOnPrintProcessor, puteți utiliza următoarele funcții: О GdiGetPageCount - obțineți numărul de pagini din document; atunci când este apelată, această funcție așteaptă finalizarea spooling-ului întregului document în format EMF; О GdiStartPageEMF - începe redarea unei pagini fizice; Despre GdiGetSpoolPageHandle - găsiți ultima pagină EMF; Despre GdiPlayPageEMF - Redați patru pagini logice, astfel încât fiecare dintre ele să ocupe un sfert de pagină fizică; Despre Gdi EndPageEMF - Încheiați redarea unei pagini fizice cu un apel către driverul de imprimantă Apelarea secvenței descrise de funcții duce la rezultat, care se numește „imprimare multiplă în ordine inversă” - cu alte cuvinte, documentul este tipărit de la sfârșit până la început, iar pe o pagină fizică se tipărește Capitolul Arhitectura grafică Windows Există mai multe (în acest caz ) pagini logice Cu această arhitectură de procesor Windows , nu trebuie să implementați aceste formatoare de documente în fiecare driver de imprimantă Este suficient să aveți un procesor de imprimare care va efectua pașii preliminari necesari pentru toate driverele compatibile Procesorul de imprimare pentru formatul EMF în Windows NT este implementat ca un DLL separat, winprint dll În Windows , funcționalitatea sa este integrată în localspl dll - PrintDocumentOnPrintProcessor este inclus în lista de funcții exportate localspl dll Pentru a schimba motorul de imprimare pentru un driver de imprimantă, accesați pagina de proprietăți a driverului și selectați fila Avansat; veți găsi butonul Procesor Prinț pe el Datele pot circula de la procesorul de imprimare în mai multe direcții Pentru datele RAW, motorul de imprimare apelează funcția WritePrinter (vezi exemplul Windows NT winprint, fișierul raw c) În acest caz, datele sunt transferate direct către monitorul de limbă Pentru datele TEXT, procesorul de imprimare apelează StartDoc și trimite comenzi grafice GDI către driverul de imprimantă În acest caz, șoferul este responsabil pentru apelarea WritePrinter Pentru datele EMF, motorul de imprimare apelează funcția Gdi EndPageEMF, care utilizează motorul de redare EMF pentru a transmite comenzile grafice înregistrate driverului de imprimantă În acest caz, funcția WritePrinter este apelată și de driverul de imprimantă Monitor de limbă și monitor de port Monitoarele de imprimare sunt responsabile pentru transmiterea datelor de imprimare de nivel scăzut de la spooler la driverul de port corect Monitoarele de imprimare sunt împărțite în două tipuri - monitoare de limbă (monitoare de limbă) și monitoare de porturi (monitoare de port) Termenul „limbaj” în acest caz nu se referă nici la limba engleză, nici la limbajul de programare C++ Se referă la o categorie specifică de limbaje pentru lucrări de imprimare (cum ar fi PJL) care sunt înțelese de software-ul încorporat al imprimantei Scopul principal al monitorului de limbă este de a oferi o comunicare bidirecțională între spoolerul de imprimare și imprimanta conectată la computer printr-un cablu care permite comunicarea bidirecțională Legătura de redirecționare (de la computer la imprimantă) este în primul rând pentru trimiterea datelor de imprimare către imprimantă Canalul de întoarcere (de la imprimantă la computer) oferă feedback Un spooler, un driver de imprimantă și chiar o aplicație de utilizator pot interoga capabilitățile și starea exactă a imprimantei (de exemplu, cantitatea de memorie instalată și disponibilă, opțiunile instalate, cantitatea de cerneală din cartus etc ) Monitorul de limbă poate furniza informațiile necesare prin apelul standard Device-loControl A doua funcție importantă a monitorului de limbă este de a insera comenzi de control al imprimantei în fluxul de date de imprimare Monitorul de porturi operează la un nivel mai scăzut decât monitorul de limbă; oferă un canal de comunicare între spooler și driverele de porturi în modul kernel, care accesează de fapt porturile I/O hardware la care se conectează imprimantele Port Monitor ca DLL personalizat Arhitectura sistemului de imprimare modul nu are acces direct la echipament Pentru a interacționa cu driverele din nucleul sistemului de operare, utilizează funcțiile obișnuite ale sistemului de fișiere API - CreateFile, WriteFile, ReadFile și DeviceloControl Monitorul de porturi este, de asemenea, responsabil pentru gestionarea porturilor logice ale imprimantei de pe computer; de exemplu, localmon dll oferă suport pentru toate porturile COM și LPT de pe computerul local Astfel, atunci când aplicația dumneavoastră scrie date pe portul LPT , aceasta nu interacționează direct cu driverul portului fizic Aplicația vorbește de fapt cu o conductă creată de spooler și controlată de monitorul portului Dacă utilizați utilitarul Winobj inclus cu SDK-ul, veți vedea că „\DosDevices\LPTl” este o legătură simbolică pentru „\Device\NamedPipe\Spooler\LPTl” Windows include mai multe monitoare de imprimare: pjlmon dll pentru o varietate de imprimante HP cu suport pentru limbajul de control al lucrărilor PJL; tcpmon dll pentru a controla portul de rețea; faxmon dll pentru driverul de fax și sfmmon dll DDK include, de asemenea, exemple de monitorizare a limbii și coduri sursă pentru monitorul de porturi, astfel încât OEM-urile să își poată crea propriile monitoare de imprimare Procesul spooler din interior Această secțiune descrie pe scurt arhitectura sistemului de imprimare Windows NT/ , concentrându-se pe spooler Pentru mai multe informații despre imprimarea API, consultați Capitolul , iar driverele de imprimantă sunt discutate mai detaliat în secțiunea Drivere de imprimantă de mai jos Dacă doriți să aruncați o privire mai atentă asupra procesului sistemului spooler în care au loc aceste evenimente interesante, este ușor să faceți acest lucru folosind Visual Studio Urmați acești pași simpli Apăsați tastele Ctrl+Alt+Del; pe ecran apare caseta de dialog Securitate Windows Selectați opțiunea Task Manager În lista de procese, selectați serviciul spooler (spoolsv exe), faceți clic dreapta pe el și selectați comanda Debug; intrați în modul de depanare al procesului sistemului de serviciu spooler Vizualizați lista modulelor VC Veți găsi DLL client spooler, router, furnizori de imprimare, procesoare de imprimare, monitoare de limbă, monitoare de porturi și alte module care nu sunt menționate mai sus Porniți o lucrare de imprimare de la panoul de control, urmăriți cum sunt încărcate DLL-urile de interfață a driverului de imprimantă și driverul de imprimantă în modul utilizator și cum sunt create și terminate firele de execuție a programului De exemplu, în Windows , Microsoft UniDriver (unidrv dll) este utilizat pe scară largă ca driver de imprimantă în modul utilizator; DLL-ul său de interfață se numește unidrvui dll Dacă închideți Visual Studio, încheind astfel procesul de serviciu spooler, nu uitați să-l reporniți cu comanda net start spooler Capitolul Arhitectura grafică Windows Pe fig Figura - prezintă unele dintre modulele încărcate de procesul de service spooler după ce sarcina de imprimare a fost creată Acest proces încarcă de module Componentele driverului de imprimantă furnizate de producătorul hardware sunt de obicei încărcate în timpul imprimării și descărcate după finalizarea tipăririi '''tfab G ■» L Ș „ Ș Ș fjjfff ¥? ■Loiejd ■ tcpmon dll D: \WI NNT \system \tcpmon dll usbmon dll D:\WI NNT \$ystem \usbmon dll u? msfaxmon dll D: \WI NNT \system \msfaxmon dll dll sfmpsprt dll D: \WI NNT \system \spool\prtprocs\w x \$fmpspr rd rnr dll D:\WINNT \system \rnr dll winrnr dll D:\WI NNT \$ystem \winrnr dll h/ nwprovau dll D: \WI NNT \system \nwprovau dll dll mpr dll D:\WINNT \system \mpr dll 'g win spl dll D:\WI NNT \$y stem \win spl dll 'ii eu clbcatq dll D: \WI NNT \$ystem \clbcatq dll oleaut dll D: \WI NNT \system \oleaut dll inetpp dll D:\WI NNT \sy $tem \inetpp dll icmp dll DAWINNT \$ystem \icmp dll : , ■ UNIDRVUI DLL D:\WINNT \system \spool\drivers\w x \ \llNID , UNIDRV DLL D: \WI NNT \system \spool\drivers\w x \ \U N D mscms dll D:\WI NNT \system \rnscrns dll T Orez Module încărcate de procesul de service spooler Mecanism grafic În secțiunea „Componentele sistemului grafic Windows”, a fost dată o diagramă cu arhitectura sistemului grafic Windows NT/ Această diagramă are o casetă mare etichetată „Motor grafic” În discuțiile anterioare despre GDI, DirectDraw și Direct D, toți apelează funcții de sistem gdi dll care sunt gestionate de motorul grafic Să aruncăm o privire mai atentă la motorul grafic Windows NT/ - coloana vertebrală a GDI, poarta de acces către driverele de dispozitive grafice și suportul de suport pentru ca aceste drivere să funcționeze Motorul grafic Windows NT/ este „ascuns” într-un DLL în mod kernel care implementează și funcționalitatea de ferestre, adică în win k sys În implementarea inițială a Windows NT, securitatea a fost un factor major în alegerea unei arhitecturi de sistem de operare, ceea ce a condus la Mecanism grafic s-a acordat respect soluțiilor compacte, simple și stabile Înainte de Windows NT , motorul grafic și sistemul de ferestre au fost implementate ca un DLL în modul utilizator care făcea parte din procesul subsistemului Win (csrss exe) Când o aplicație a numit o funcție de fereastră sau de desen, de fapt apela un proces subsistem Win prin mecanismul LPC Acesta din urmă a accesat motorul grafic sau sistemul de ferestre din firul său de program și a returnat rezultatul în aplicație Comutarea proceselor și firelor de execuție în această arhitectură a dus la o supraîncărcare semnificativă a memoriei și a procesorului În Windows NT și noul Windows , motorul grafic și sistemul de ferestre au fost mutate în modul kernel User dll și gdi dll apelează acum funcții de sistem pe care ntoskrnl le transmite la win k sys fără schimbarea procesului sau a firelor Astfel, win k sys poate fi văzut ca implementarea de referință la nivel de kernel a două module importante ale sistemului Windows: user dll și gdi dll Biblioteca win k sys este mare ( KB pe Windows ) - chiar mai mare decât ntoskrnl exe ( KB pe Windows ) Arhitectura internă a win k sys este practic necunoscută lumii exterioare Microsoft documentează un singur lucru: interfața DDI folosită de driverul dispozitivului grafic win k sys exportă aproximativ de funcții, nu prea mult în comparație cu cele de funcții ale lui ntoskrnl exe Consultați www sysinternal com pentru o listă completă a surselor de nucleu Windows beta , proiectate invers dintr-o versiune de depanare a sistemului de operare Cu toate acestea, acest lucru se aplică numai pentru ntoskrnl exe; nu există nimic similar pentru win k sys Din fericire, documentația pentru interfața DDI (adică interfața dintre motorul grafic și driverele dispozitivului grafic) din Microsoft NT/ DDK este foarte bine scrisă Pe fig Figura arată cum ar putea arăta motorul grafic din punct de vedere arhitectural (pe baza documentației DDK și a cercetărilor proprii ale autorului) Motorul grafic are o arhitectură pe mai multe niveluri La nivelul superior se află tabelul cu funcțiile sistemului, care formează un singur punct de intrare din aplicațiile în modul utilizator Interfețele DirectDraw, Direct D și GDI de sub acesta comunică cu driverul de afișare printr-o cale mai scurtă Pentru apelurile GDI obișnuite, există un strat API GDI care convertește constructele GDI în primitive care sunt ușor de înțeles de motorul de mapare DIB și driverele de dispozitive grafice Stratul API GDI folosește un manager GDI pentru a gestiona structurile de date interne, un motor de randare pentru redarea primitivelor GDI pe suprafețe bitmap acceptate de GDI, un motor de scalare, drivere pentru cele trei tipuri de font GDI și alte componente Motorul grafic Windows NT/ , spre deosebire de motorul Windows / , este suficient de puternic pentru a reda toate primitivele DII pe suprafețele standard DIB fără ajutorul driverelor de dispozitive grafice Pentru suprafețele bitmap non-standard, motorul grafic apelează driverele de dispozitiv și le instruiește să redea primitivele DDI Șoferii pot apela la motorul grafic cu o cerere de contor - de exemplu, solicită informații suplimentare, da instrucțiuni, Capitolul Arhitectura grafică Windows pentru ca motorul grafic să descompună comenzile în altele mai mici și chiar să ceară motorului de vizualizare să ajute cu rezultatul Mecanism grafic Tabelul funcțiilor sistemului motorului grafic GDI API Layer DirectDraw Direcr D MCD Manager de manipulare Scaler Motor de randare Driver de font True Type Driver de font Bitmap Driver de font Vector Emulare de calcul real Operații Pluon Server MCD Drivere pentru producătorii de hardware driver de imprimantă Driver de font Fonturi Mini driver pentru portul video (VPE, DxApi, TV) Driver de ecran (DirectDraw, Direct D, MCD) Orez Arhitectura motorului grafic Windows Componentele individuale ale motorului grafic Windows sunt descrise mai jos Funcțiile sistemului motor grafic După cum s-a menționat în secțiunea Arhitectură GDI, gdi dll conține sute de funcții grafice utilizate de bibliotecile de componente ale subsistemului Win (și anume GDI, DirectDraw, Direct D și OpenGL) pentru a accesa motorul grafic găsit în nucleul sistemului de operare Textul includea chiar și un program pentru a afișa o listă de apeluri de funcții de sistem de la aceste DLL-uri Gestionarea efectivă a apelurilor de funcții de sistem este gestionată de modulul win k sys Conține tabelul cu funcțiile de sistem, care include funcțiile de sistem ale motorului grafic împreună cu funcțiile de sistem ale sistemului de ferestre În timpul procesului de inițializare win k sys, tabelul este înregistrat de managerul de funcții ale sistemului OS, ceea ce asigură că apelurile de funcții ale sistemului sunt transmise rapid motorului grafic Dacă aveți fișiere cu simboluri de depanare Windows NT/ instalate pe computer, puteți utiliza programul dumpbin pentru a vizualiza numele simbolurilor win k sys Acesta este un utilitar destul de puternic care poate fi apelat pe fișierele Win PE, fișierele obiect și fișierele simbol de depanare Următoarele două comenzi vă permit să obțineți o listă a tuturor numelor simbolice din fișierul win k sys și să căutați cuvântul Service (funcția de sistem) simboluri dumpbin\sys\win k dbg /all > tmpflle grep Service tmpflle Mecanism grafic Se găsește un nume destul de interesant, W pServiceTable este adresa de pornire a unui tabel de pointeri către toți gestionatorii de funcții de sistem win k sys Programul SysCall (vezi secțiunea Arhitectură GDI) vă permite să enumerați elementele unui tabel, să le convertiți în nume simbolice și să le afișați într-o fereastră Rulați programul SysCall și selectați comanda View ► System Caii Tables ► Win k sys system caii table - apare o listă de (în Windows ) de gestionare a funcțiilor de sistem pentru motorul grafic și sistemul de gestionare a ferestrelor (Fig ) syscall D: WINNT \System \win k sys încărcat D:\UNINNT \symbo s\sys\win k dbg loaded syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) syscall( ) c) syscall( d) syscall( e) syscall(lOOf) syscall( ) syscall( ) syscall( ) NtGdi Âbor t Doc NtGdiabortPath NtGdi ÂddF pe t ResourceU NtGdi ÂddRemo t eFon t T oDC NtGdi ÂddF pe t MemResourceEx NtGdi RemoveMergeFon t N t Gd i ÂddRemo t eMMIns t anceToDC N t Gd i Â phaB end NtGdi Âng eÂrc NtGdi ÂnyL i nkedF pe ts NtGdiFontlsLinked NtGdi ÂrcInt erna NtGdiBeginPath NtGdiBitBlt NtGdiCanoe DC NtGdi CheckB it mapB it N t Gd i C oseF i gure NtGdiColorCorrectPalette NtGdi Comb i neRgn Orez Lista funcțiilor sistemului motorului grafic NOTĂ - Celălalt furnizor major de funcții de sistem în Windows NT/ este runtime, găsit în fișierul ntoskrnl exe Funcțiile sale sunt apelate prin subsistemul Win DLL ntdll dll Acestea oferă suport pentru un serviciu Win de bază, denumit în mod obișnuit un serviciu kernel, ale cărui funcții sunt exportate în principal din kernel dll Executivul folosește funcții de sistem cu ID-uri mai mici de x , iar restul ID-urilor sunt folosite de motorul grafic și sistemul de ferestre Programul SysCall vă permite să obțineți o listă de funcții de sistem în ntdll dll și conținutul tabelului cu funcții de sistem din ntoskrnl exe Spre deosebire de găsirea tuturor locurilor din care sunt apelate funcțiile de sistem, listarea conținutului tabelului de funcții de sistem pentru programul SysCall este o sarcină elementară Tot ceea ce este necesar pentru aceasta este să citiți continuu din imaginea win k sys încărcată conținutul adreselor, începând cu W pServiceTable, Capitolul Arhitectura grafică Windows și convertiți-le în nume simbolice folosind un fișier simbolic de depanare După descrierea funcțiilor sistemului GDI (inițialând întreruperea x E), lista de gestionare a funcțiilor sistemului motorului grafic (adică fragmentele care servesc întreruperea x E pentru diferiți indici de funcție) pare familiară - cu excepția win k sys, această listă este ordonată după indexul funcției sistemului și completat Microsoft folosește aceleași nume pentru funcțiile asociate de la gdi dll și win k sys De exemplu, funcția NtGdiAbortDoc cu index x este prezentă în ambele tabele Numele funcțiilor motorului grafic, cu rare excepții, încep cu NtGdi, iar numele funcțiilor de gestionare a ferestrelor încep cu NtUser De regulă, pentru fiecare funcție de sistem a motorului grafic, este ușor să găsiți un prototip printre funcțiile GDI, DirectDraw, Direct D, OpenGL sau funcțiile de suport pentru driverul de imprimantă În alte cazuri, funcțiile sistemului pot fi destinate exclusiv utilizării interne Exemple: O funcție de sistem NtGdiAbortDoc, desigur, implementează funcția GDI AbortDoc; A Funcția de sistem NtGdiDdBlt este legată de interfața DirectDraw IDirectDrawSurface; A Funcțiile de sistem NtGdiDoBanding și NtGdiGetPerBandInfo sunt utilizate la imprimarea paginilor pe benzi; Funcțiile sistemului NtGdiCreateCl ientObj și NtGdiDel eteCl ientObJ par criptice la prima vedere, dar după ce citiți Capitolul veți înțelege pentru ce sunt acestea; A Funcțiile de sistem NtGdiGetServerMetafileBits și NtGdiGetSpoolMessage sunt utilizate în mod explicit de către spooler Motor de randare grafică Să trecem la baza întregului motor grafic Windows NT/ , motorul de randare grafică (GRE) După ce vă familiarizați cu acesta, vă va fi mult mai ușor să înțelegeți cum funcționează motorul grafic în general Cu Windows NT/ , Microsoft a inclus randeri complete pentru toate formatele standard DIB, inclusiv DIB-uri cu adâncimi de culoare de , , , , și de biți/pixel Dacă dispozitivul de ieșire folosește unul dintre aceste formate DIB, motorul grafic nu are nevoie de ajutorul driverelor de dispozitiv pentru a desena linii, umpleri, hărți de biți sau text În schimb, un driver de dispozitiv grafic poate utiliza serviciile motorului grafic pentru a implementa apeluri grafice GDI Dacă se dorește, driverul dispozitivului poate construi imaginea în sine - de exemplu, pentru a obține performanțe comparabile cu DirectDraw / Direct D sau când se utilizează configurații hardware speciale Ca urmare, complexitatea driverelor obișnuite pentru dispozitive grafice este redusă, sistemul de operare este mai stabil, iar dezvoltarea produsului este accelerată atât de producătorii de hardware, cât și de Microsoft însuși Mecanism grafic GRE este utilizat atât de motorul grafic, cât și de driverele dispozitivului grafic; conține majoritatea funcțiilor exportate de motorul grafic Aceste funcții sunt documentate în detaliu în secțiunea „Funcții GDI pentru drivere grafice” din Windows NT/ DDK GRE API este foarte diferit de Win GDI API Mai jos sunt enumerate câteva dintre conceptele generale utilizate de GRE și de motorul grafic în general Despre Operațiuni cu rastere la nivel GDI Sunt acceptate toate formatele DIB standard, inclusiv DIB-urile necomprimate la , , , , și de biți pe pixel, precum și DIB-urile comprimate la și biți per pixel în codificare RLE (Run Length Encoding) DIB poate fi stocat în memorie atât în formă directă (de jos în jos), cât și în formă inversată (de sus în jos) Memoria pentru datele grafice DIB poate fi alocată din spațiul de adrese kernel sau din spațiul de adresă al procesului utilizatorului Funcția End-CreateBitmap, exportată de pe win k sys, creează o hartă de biți controlată de GDI și îi returnează mânerul O Coordonați spațiul Pentru a îmbunătăți precizia de ieșire fără a utiliza calcule reale, GRE poate lucra cu coordonate fracționale în format de punct fix (cu alte cuvinte, cei de biți superiori definesc partea întreagă cu semn, iar cei biți inferiori definesc partea fracțională) Acestea sunt așa-numitele „coordonate FIX” folosite la desenarea liniilor și a curbelor În alte componente API, coordonatele sunt reprezentate ca numere întregi semnate pe de biți Toate apelurile la funcții grafice suferă o transformare preliminară a coordonatelor, așa că GRE nu are conceptele de coordonate ale ferestrei și transformări de porturi de vizualizare, extinse și lumii Dimensiunea maximă a unei suprafețe DIB este de x pixeli, adică , km x , km la o rezoluție de dpi Despre Surface GRE oferă control deplin pentru un singur tip de suprafață - hărți de biți gestionate de GDI Driverele de dispozitiv pot crea suprafețe gestionate de dispozitiv în DIB sau în alte formate folosind funcția End-CreateDewiceSurface Driverul controlează apoi ieșirea grafică către acele suprafețe Un exemplu de suprafață Win non-DIB gestionată de dispozitiv este hărțile de biți dependente de dispozitiv О Interceptarea și returnarea apelurilor În mod implicit, GRE produce toate rezultatele pe suprafețele DIB gestionate de GDI Cu toate acestea, driverul dispozitivului poate intercepta apelurile către anumite funcții grafice pentru a le implementa în felul său Steagul flHook al funcției EngAssociateSurface determină ce funcții sunt conectate de șofer De exemplu, un driver poate furniza propria sa funcție DrvBitBlt prin trecerea steagului HOOK BITBLT atunci când apelează EngAssociateSurface În consecință, solicitările de blitting vor fi trimise către DrvBitBlt Cu toate acestea, atunci când DrvBitBlt este apelat, se poate determina că operația este prea complexă În acest caz, șoferul returnează o solicitare GDI apelând EngBitBlt Capitolul Arhitectura grafică Windows Despre primitivele grafice Motorul grafic reduce multe dintre caracteristicile grafice Win la un număr mic de primitive care sunt acceptate de GRE Mai jos este un rezumat al primitivelor: □ EngLineTo și EngStrokePath - toate operațiunile pentru trasarea liniilor și curbelor; □ EngFillPath și EngPaint - umplerea unei zone închise cu o perie; □ EngStroke și FillPath - umplerea unei zone închise cu o perie și mângâierea conturului; □ EngBitBlt, EngPlgBlt, EngStretchBlt, EngStretchBl tROP, EngCopyBits, EngAlphaBlend și EngTransparentBlt — ieșire raster; □ EndGradientFill - umplerea cu gradient a zonelor; □ EngTextOut - tot textul ieșit Pe lângă primitivele grafice simplificate, GRE utilizează un set complet nou de structuri de date Nu este vorba deloc despre manipulatorii GDI; de fapt, GRE există sub (sau, dacă preferați, în spatele) stratului de manipulatoare GDI Următoarele sunt câteva dintre clasele de obiecte asemănătoare C++ utilizate de GRE: О CLIPOBJ — zonă de tăiere; o PATHOBJ - calea instrumentului GDI (și toate curbele convertite în trasee de scule); Despre PALOBJ și XLATEOBJ - conversie de culoare; DESPRE BRUSHOBJ - pensule si pixuri GDI; Despre FONTOBJ - font implementat; Despre STROBJ - pozițiile glifelor în textul de ieșire; Despre XFORMOBJ - folosit pentru a transforma coordonatele atunci când lucrați cu FONTOBJ; Despre SURFOBJ este o suprafață grafică Deși GRE are o interfață mult mai simplă decât Win API, principalele probleme sunt legate de implementarea tuturor celor mai mici detalii Imaginează-ți doar de câte tipuri de funcții de blitting vei avea nevoie - cel puțin Consultați informațiile de depanare win k sys - veți găsi nume simbolice precum bSrcCopySRLE D , vSrcS D , vSrcCopyS D , vSrcCopyS D , vSrcCopyS D , vSrcCopySRLE D , vSrcCopySRLE D etc , bSrcCopySRLE D , aparține unei funcții de copiere a bitmap-urilor sursă de biți comprimate cu RLE într-un bitmap de destinație de de biți Al treilea nume, vSrcCopyS D , sugerează o funcție pentru a copia o sursă de de biți într-o destinație de biți Nu uitați că există operații binare și ternare bitmap, ca să nu mai vorbim de operațiuni cuaternare care combină două operații ternare Structuri de date ale motorului grafic GDI, la fel ca multe alte componente Win API, ascunde implementarea sa de programatorii cu mânere de obiecte GDI Acest nivel de abstractizare este extrem de util pentru a defini mai mult sau mai puțin Mecanism grafic API-ul Win comun în loc de implementări diferite pentru Win s, Windows / și Windows NT/ Ca și în cazul oricărui strat abstract, cineva trebuie în cele din urmă să gestioneze mânerele GDI, făcându-le utilizabile atât în DLL-uri de sistem în modul utilizator, cât și în modul kernel Modulul care gestionează mânerele GDI se numește managerul mânerului GDI Următoarea întrebare este mai dificilă - cum este organizată gestionarea structurii de date în modul utilizator DLL și în motorul în modul kernel și cum sunt informațiile Win GDI despre contextele dispozitivului, pixurile logice, pensulele logice, fonturile, regiunile, căile etc convertit în structuri de date ale motorului grafic? Cunoașterea structurilor de date utilizate în funcționarea GDI îl va ajuta pe programator să înțeleagă mai bine implementarea API-ului GDI și să își optimizeze programele Vom explora acest subiect în capitolul și vom încerca să găsim răspunsuri la întrebările puse Conversia la primitive Există un decalaj vizibil între API-ul Win GDI și primitivele grafice suportate de GRE (care formează și interfața DDI cu driverele de dispozitiv) Stratul API GDI este responsabil pentru conversia apelurilor API GDI Win în primitive GRE Mai jos sunt enumerate câteva dintre diferențele care trebuie modificate O Sistemul de coordonate Win API acceptă un sistem de coordonate flexibil cu transformări de ferestre/vizualizări, moduri de afișare și transformări ale lumii, în timp ce GRE/DDI funcționează în coordonate fizice scalate în funcție de dimensiunea suprafeței de ieșire Coordonatele din apelurile de funcție Win API trebuie convertite în coordonatele fizice ale suprafeței grafice Despre curbe eliptice Interfața GRE/DDI nu acceptă curbe eliptice precum cercuri sau elipse - aceste curbe trebuie convertite în curbe Bezier Capitolul oferă un exemplu de reprezentare a unei elipse cu patru curbe Bezier În timpul procesului de conversie, motorul grafic trebuie să emuleze calculele în virgulă mobilă Coordonatele punctului fix utilizate de interfața DDI îmbunătățesc acuratețea rezultatului final О Convertiți curbele în trasee Interfața DDI funcționează numai cu linii drepte și trasee, astfel încât toate curbele trebuie convertite intern în obiecte trasee Motorul grafic are un set bogat de funcții interne pentru operațiuni cu obiecte de traiectorie Dacă suprafața este condusă de dispozitiv, driverul de dispozitiv este necesar să accepte setul minim de caracteristici - DrvPaint, DrvCopyBits, DrvTextOut și DrvStrokePath Funcțiile rămase sunt împărțite de mecanismul grafic într-un set de aceste operații Unele dintre acțiunile efectuate de GDI sunt enumerate mai jos Capitolul Arhitectura grafică Windows A Când desenați linii cosmetice și curbe, funcția DrvStrokePath trebuie să suporte linii cosmetice solide și stilizate, cu periere și decupare uniforme În implementarea DrvStrokePath, driverul poate apela funcțiile utilitare pentru obiecte PATHOBJ și CLIPOBJ pentru a descompune parametrii până la linii de pixel și dreptunghiuri de tăiere Dacă traiectoria sau zona de tăiere este prea complexă, șoferul poate redirecționa apelul către motorul grafic, care descompune apelul la linii groase de pixel cu o tăiere precalculată Pentru a împărți liniile de stil și curbele Bezier, GDI le aproximează cu segmente de linie dreaptă A Liniile geometrice au atribute pentru grosime, stil de îmbinare și capac de capăt Dacă driverul de dispozitiv nu se poate ocupa de trasarea unei astfel de linii, acesta convertește apelul de funcție în apeluri mai simple la DrvFillPath sau DrvPaint În acest caz, operația de desenare este convertită într-o umplere a zonei A Pentru a umple zonele, driverul trebuie să accepte DrvPaint O implementare DrvPaint poate folosi funcțiile utilitare CLIPOBJ pentru a împărți o regiune complexă de tăiere într-o colecție de dreptunghiuri de tăiere A Pentru funcțiile de blitting, driverul trebuie să accepte funcția DrvCopyBits, care ar efectua un transfer în bloc de date grafice către sau de la un DIB standard, precum și către un bitmap în format dispozitiv, cu tăiere arbitrară DrvCopyBits efectuează o copiere simplă fără întindere, oglindire sau aplicarea de operații bitmap Dacă driverul de dispozitiv este limitat la a accepta DrvCopyBits, motorul grafic trebuie să emuleze operația dorită în memorie și să aplice DrvCopyBits rezultatului Relația dintre motorul grafic și driverele de dispozitiv este oarecum ca o relație părinte-copil Motorul grafic oferă tot suportul necesar pentru driverele de dispozitiv Șoferii pot face tot ce doresc pentru a depăși motorul grafic, dar când rămân blocați, apelează la motorul grafic pentru ajutor Drivere de font În Windows NT / , există un tip special de driver de dispozitiv grafic care furnizează sistemului contururi sau hărți de biți ale pictogramelor de font Astfel de drivere se numesc drivere de font La nivel de sistem, Windows acceptă trei tipuri de fonturi bazate pe tehnologii diferite Fonturile bitmap sunt imagini bitmap ale caracterelor, caracterele vectorului fonturi sunt construite din segmente de linie, iar fonturile TrueType se bazează pe curbele Bezier și un motor de marcare ingenios (sugestie) În consecință, în activitatea sa internă, motorul grafic utilizează trei drivere de font - pentru fonturile bitmap, pentru fonturile vectoriale și pentru fonturile TrueType Drivere de ecran Sistemul poate utiliza, de asemenea, drivere de font externe De exemplu, un driver de imprimantă poate include un driver de font care furnizează sistemului grafic informații despre fonturile de imprimantă Un alt exemplu este driverul de font ATM (Adobe Type Manager) atmfd dll, inclus cu Windows Driverul de font ATM oferă suport pentru fonturile ATM bazate pe tehnologia de fonturi PostScript de la Adobe Drivere de ecran Driverul de afișare din Windows NT/ este clasificat ca driver de dispozitiv grafic De obicei, driverele de dispozitive grafice sunt DLL-uri în modul kernel care sunt încărcate în spațiul de adrese al nucleului Aceștia sunt responsabili pentru implementarea finală a apelurilor grafice transmise de aplicația utilizator către dispozitiv Pe Windows NT/ , driverele de dispozitiv sunt întotdeauna DLL-uri în modul kernel Doar driverele de imprimantă din Windows pot fi implementate ca DLL în modul utilizator Interfața dintre motorul grafic GDI și driverul dispozitivului grafic se numește DDI (Device Driver Interface) De ce este folosit termenul generic „driver de dispozitiv” în acest caz, chiar dacă se referă doar la driverele de dispozitiv grafic? Probabil pentru că, pe vremuri, driverele grafice erau singura categorie notabilă de drivere furnizate de producătorii de hardware Driver pentru portul video și driverul pentru portul video mini Fiecare driver de afișare are un mini-driver pentru portul video asociat, care rulează în modul kernel Prefixul „mini” indică faptul că există un alt driver „maxi” care controlează funcționarea mini-șoferului În acest caz, mini-driverul portului video este controlat de driverul portului video Driverul portului video și minidriverul portului video gestionează toate interacțiunile dintre sistem și adaptorul video, inclusiv inițializarea și recunoașterea cardului, maparea memoriei, accesul la registrul adaptorului video și așa mai departe, prin mecanismul standard de acces la memorie În Windows , care este proiectat să accepte DirectX la nivel de driver video, mini-driverul portului video este, de asemenea, responsabil pentru suportul DirectX De exemplu, unul dintre cele mai importante avantaje ale DirectX față de GDI este că aplicației utilizatorului i se oferă acces direct la memoria tampon de memorie video Această capacitate este realizată cu un mini-driver pentru portul video care mapează tamponul la o zonă de adrese virtuală accesibilă aplicațiilor utilizatorului Driverul de afișare comunică cu mini-driverul portului video prin apeluri către funcția EngDewiceloControl a motorului grafic, care sunt transmise Capitolul Arhitectura grafică Windows sunt trimise de managerul I/O al nucleului NT către driverul portului video și apoi trecute către driverul portului video mini Atribuirea driverului de ecran Deși accesul direct la hardware-ul video este oferit de mini-driverul portului video, acesta este de obicei sub controlul driverului de afișare Sarcinile efectuate de driverul de ecran sunt împărțite în patru clase A Acordați și refuzați accesul la resursele hardware grafice, inclusiv maparea memoriei video, băncile și heap off-screen, cursorul mouse-ului hardware, paleta hardware, memoria cache a pensulei și suportul hardware DirectDraw/Direct D/OpenGL (dacă există) De obicei, driverul de afișare transmite cereri către driverul portului video A Transmiterea de informații despre hardware și capabilitățile driverului către motorul GDI prin structuri speciale de date GDI О Creați și actualizați suprafețe Acestea pot fi suprafețe DIB conduse de GDI, suprafețe DIB conduse de dispozitiv sau suprafețe comandate de dispozitiv în alte formate О Implementarea operațiilor grafice de bază (sau a tuturor) cu suprafața prin crearea de interceptori Driverul de ecran poate, de asemenea, să creeze o suprafață condusă de GDI și să lase motorul grafic să lucreze direct cu ea Inițializarea driverului de ecran Driverul de ecran este de obicei un DLL în modul kernel care importă doar funcții din motorul grafic (win k sys) Punctul de intrare al driverului de ecran principal, la același offset ca DllMainCRTStartup, este de obicei numit DrvEnableDriver Funcția DrvEnableDriver este de obicei apelată de GDI după ce driverul este încărcat Driverul efectuează o verificare simplă a versiunii și returnează un tabel de funcții motorului GDI care listează toate funcțiile DDI pe care le acceptă Tabelul este returnat ca structură DRVENABLEDATA Fiecare funcție DDI acceptată de driverul de afișare Windows NT/ are un index predefinit Windows definește un total de de funcții DDI De exemplu, DrvEnableDriver are o funcție de pereche DrvDisableDriver cu index După primirea tabelului de funcții, motorul grafic apelează de obicei DrvEnablePDEV pentru ca driverul să instanțieze dispozitivul fizic și să returneze informații importante despre hardware-ul grafic și driver Când este apelat DrvEnablePDEV, motorul grafic transmite driverului o copie a structurii DEVM DEW care descrie caracteristicile dispozitivului grafic Pentru adaptoarele video, DEVMODEW definește rata de reîmprospătare, rezoluția și modurile speciale (cum ar fi tonuri de gri sau ieșire întrețesată) Pentru imprimante, DEVMODEW conține informații și mai importante despre tipul și dimensiunea hârtiei, orientare, calitatea imprimării, numărul de copii și metoda de alimentare Drivere de ecran DrvEnablePDEV instanțiază o structură PDEV (Physical Device) definită de șofer și care conține datele private ale șoferului Funcția returnează un handle de structură PDEV, prin care motorul GDI se referă la această instanță de dispozitiv fizic la apelurile ulterioare În plus, DrvEnablePDEV populează o structură GDIINFO din care GDI obține informații despre rezoluția dispozitivului, dimensiunea fizică, formatul de culoare, biți DAC, raportul de compresie verticală, dimensiunea paletei, ordinea planului de culoare, dimensiunea și formatul modelului de semitonuri, rata de reîmprospătare etc de asemenea, returnat într-o structură DEVINFO care descrie capacitățile grafice ale driverului, fonturile implicite, numărul de fonturi pentru dispozitiv și formatul de amestecare a culorilor Indicatoarele de capacitate grafică indică motorului grafic dacă dispozitivul acceptă procesarea Bezier, expansiune geometrică, tipuri de umplere poligonală (ALTERNATE sau WINDING), imprimare EMF, netezire a textului, rasterizare hardware a fonturilor, JPEG, încărcare tabel gamma, suport hardware al cursorului alfa etc e După apelarea DrvEnablePDEV, motorul grafic realizează propria inițializare internă a dispozitivului fizic și în cele din urmă apelează DrvCompleteDEV, indicând astfel că dispozitivul fizic este gata de utilizare Când PDEV se termină, este apelată funcția DrvDi sabl ePDEV, care de obicei eliberează memoria alocată dispozitivului fizic Înainte ca GDI să înceapă să iasă pe dispozitiv, motorul grafic apelează DrvEnableSurface pentru ca driverul să creeze suprafața grafică Dacă adaptorul video funcționează cu un framebuffer DIB standard, acesta creează o suprafață condusă de GDI apelând EngCreateBitmap În caz contrar, driverul de ecran alocă memorie pentru suprafața în sine și folosește EngCreateDeviceSurface pentru a spune motorului grafic dimensiunea și formatul compatibil al suprafeței În ambele cazuri, driverul de dispozitiv apelează apoi EngAssociateSurface pentru a specifica ce apeluri de operare grafică DDI ar trebui să fie interceptate de driver Aceasta utilizează informații din tabelul de funcții returnate la apelarea DrvEnableDriver Când suprafața este terminată, motorul grafic apelează DrvDi sabl eSurface pentru a permite șoferului să elibereze toate resursele alocate Concluzie la suprafață, interceptare și întoarcere După crearea cu succes a suprafeței, motorul grafic transmite apeluri grafice driverului de dispozitiv în funcție de biții de capacitate setați și de steaguri de conectare pentru suprafață În tabel Tabelul enumeră toate operațiunile de ieșire DDI care pot fi interceptate la ieșire la suprafață După cum se poate observa din tabel, fiecare operație grafică DDI din motorul GRE are un analog cu exact aceiași parametri, conceput pentru a efectua această operație pe o suprafață standard în format DIB Următoarele listează opțiunile pentru implementarea apelurilor DDI grafice de către driver R Pentru suprafețele în format standard DIB, șoferul poate renunța la interceptarea funcțiilor grafice DDI și poate lăsa GRE să se ocupe de toate operațiunile grafice De exemplu, exemplul de driver din Windows DDK nu conectează niciuna dintre funcții (ddk\src\video\displays\framebuf) Capitolul Arhitectura grafică Windows Tabelul Operațiuni grafice Windows interceptate Index Funcția motorului grafic Funcția șofer HOOK-BITBLT EngBitBlt DrvBitBlt HOOK STRETCHBLT EngStretchBlt DrvStretchBlt HOOK PLGBLT EngPlgBlt DrvPlgBlt HOOKTEXTOUT EngTextOut DrvTextOut HOOK PAINT EngPaint DrvPaint HOOKSTROKEPATH EngStrokePath DrvStrokePath HOOK FILLPATH EngFillPath DrvFillPath HOOKSTROKANDFILLPATH EngStrokeAndFi Path DrvStrokeAndFi Path HOOKLINETO EngLineTo DrvLineTo HOOKCOPYBITS EngCopyBits DrvCopyBits HOOKMOVEPANNING EngMovePanni ng DrvMovePanning HOOK SYNCHRONIZE EngSynchronize DrvSynchronize HOOK STRETCHBLTROP EngStretchBltROP DrvStretchBltROP HOOKSYNCHRONI ZEACCESS EngSynchroni zeAccess DrvSynchroni zeAccess HOOK TRANSPARENTBLT EngTransparentBlt DrvTransparentBlt HOOK ALPHABLEND EngAlphaBlend DrvAlphaBlend HOOK GRADIENTFILL EngGradientFill DrvGradientFill R Dacă suprafața este condusă de dispozitiv, driverul poate intercepta câteva primitive necesare și poate lăsa motorul grafic să descompună toate celelalte apeluri în primitive De asemenea, driverul poate intercepta toate apelurile grafice pentru a aplica accelerarea hardware sau o implementare software optimizată De exemplu, exemplul de driver s virge din Windows DDK oferă o implementare optimizată a asamblatorului pentru un fel de blitting între ecranul tampon și DIB-urile off-screen În acest caz, apelurile către DrvBitBlt trebuie interceptate A O funcție de cârlig implementată de șofer poate apela funcții ale sistemului de motor grafic pentru a împărți o regiune complexă de tăiere în grupuri mai simple de dreptunghiuri De asemenea, șoferul poate returna apelurile GRE atunci când nu își face treaba De exemplu, driverul s virge menționat mai sus returnează un apel către motorul grafic pentru a efectua blitting între două DIB-uri în afara ecranului Drivere de ecran Caracteristici suplimentare ale driverului Pe lângă inițializarea/terminarea și interceptarea apelurilor DDI grafice, driverul de afișare trebuie să prezinte și puncte de intrare motorului grafic pentru a efectua următoarele operațiuni: Despre gestionarea bitmap-ului dispozitivului: DrvEnableDeviceBitmap și DrvDisableDeviceBitmap; Despre gestionarea paletelor: DrvSetPalette; Despre implementarea pensulelor, suport pentru amestecarea culorilor (dithering) și ICM (Image Color Management): DrvRealizeBrush, DrvDitherColor, DrvIcmCreateColorTransform, DrvIcmCheckBitmapsBits etc ; O soluții GDI: DrvEscape, DrvDrawEscape (de exemplu, pentru PostScript pass-through); О control mouse: DrvSetPointerShape, DrvMovePointer; О Obținerea de informații despre fonturi și drivere de fonturi compatibile: Drv-QueryFont, DrvQueryFontTree, DrvQueryFontData, DrvQueryFontFile, DrvQueryTrueType-FontTable etc ; O imprimare: DrvQuerySpoolType, DrvStartDoc, DrvEndDoc, DrvStartPage, DrvEndPage etc (imprimarea este discutată în detaliu în capitolul ); o Suport OpenGL: DrvSetPixelFormat, DrvSwapBuffers, etc ; o Suport DirectDraw/Direct D: DrvEnableDirectDraw, DrvGetDirectDrawInfo și DrvDi sableDirectDraw Multe dintre aceste funcții sunt opționale și sunt implementate de driverul dispozitivului grafic numai dacă dispozitivul are capabilitățile hardware corespunzătoare Suport DirectDraw/Direct D la nivel de driver de ecran Dacă driverul de afișare acceptă DirectDraw/Direct D, trebuie să exporte punctul de intrare DrvGetDirectDrawInfo prin care motorul grafic începe să interacționeze cu suportul hardware DirectDraw Când o aplicație DirectDraw/Direct D instanțiază un obiect DirectDraw, motorul grafic apelează mai întâi DrvGetDirectDrawInfo pentru a obține informații de asistență DirectDraw de la driverul de afișare DrvGetDirect-DrawlInfo returnează informații GDI despre suportul DirectDraw/Direct D, inclusiv o descriere a capabilităților hardware și o listă de formate acceptate Informațiile despre capabilitățile hardware (blitting hardware, scalare, suport pentru canal alfa, tăiere, chei de culoare, suprapuneri, palete, suport Direct D etc ) sunt codificate în structura DD HALINFO Informațiile despre formatele de memorie video sunt returnate ca o serie de structuri VIDEOMEMORYINFO Fiecare format este codificat cu o valoare FOURCC pe de biți, care este utilizată pentru a desemna tipul media în API-ul multimedia DirectDraw folosește FOURCC pentru a descrie formatele de pixeli acceptate de adaptoarele video și formatele de pixeli în texturi comprimate Capitolul Arhitectura grafică Windows Motorul grafic apelează apoi funcția DrvEnableDirectDraw, indicând astfel driverului să activeze suportul hardware pentru VigesDirectDraw Funcția DrvEnableDirectDraw umple trei structuri cu adresele funcțiilor de apel indirect pentru interfețele IDirectDraw, IDirectDrawSurface și IDirectDrawPalette Ceva similar se întâmplă în punctul de intrare al driverului de ecran principal, DrvEnableDriver, care returnează o listă indexată de funcții de apel indirect pentru implementarea DDI Fiecare dintre cele trei structuri de date returnate de DrvEnableDirectDraw corespunde uneia dintre componentele principale ale interfeței DirectDraw (vezi descrierea DirectDraw API) Structura include un câmp de steaguri care specifică funcțiile de indirectare acceptate și indicii către toate funcțiile de indirectare ale acestei interfețe De exemplu, structura DDCALLBACKS se referă la implementarea DirectDraw și conține informații despre nouă funcții de apel indirect Dacă indicatorul DDHAL CB CREATESURFACE este prezent în câmpul dwFlags, atunci câmpul CreateSurface conține adresa funcției de apel indirect, care este de obicei numită DdCreateSurface De fapt, interfața IDirectDraw conține mai mult de nouă metode Unele dintre metode sunt implementate în interiorul DLL-ului client DirectDraw Win , în timp ce restul funcțiilor la nivel de driver sunt returnate în alte structuri (de exemplu, DD NTCALLBACKS) Suportul Direct D din partea driverului de afișare este indicat de mai multe steaguri în structura DD HALINFO returnată de DrvGetDirectDrawInfo Indicatorul DDCAPS D din câmpul ddCaps dwCaps înseamnă că dispozitivul deservit de driver acceptă accelerarea grafică D Indicatoarele din câmpul ddCaps ddsCaps (de exemplu, DDSCAPS DDEVICE, DDSCAPS TEXTURE și DDSCAPS ZBUFFER) descriu capabilitățile D pentru suprafața memoriei video În plus, DD HALINFO conține un pointer către o structură D DNTHAL CALLBACKS care conține adresele funcțiilor de apel indirect Direct D DDI În tabel listează unele structuri care transmit informații despre funcțiile de suport DirectDraw/Direct D în driverul de afișare Tabelul Funcții DDI indirecte DirectDraw/Direct D (listă parțială) Funcții de structură DDCALLBACKS DdDestroyDriver, DdCreateSurface, DdSetColorKey, DdSetMode, DdWai tForVerti cal Blank, DdCanCreateSurface, DdCreatePalette, DdGBetScalLine, DdMapMemory DDSURFACECALLBACKS DdDestroySurface, DdFlip, DdSetClipList, DdLock, DdUnlock, DdBlt, DdSetColorKey, DddAddAttachedSurface, DdGetBltStatus, DdGetFlipStatus, DdUpdateSetOverlay, DPodPass DDPALETTECALLBACKS DdDestroyPalette, DdSetEntries DD NTCALLBACKS DdFreeDriverMemory, DdSetExclusiveMode, DdFlipToGDISurface DDCOLORCONTROLCALLBACK-uri DdColorControl DD MISCELLANEOUSCALLBACKS DdGetAvai Dri verMemory Drivere de imprimantă Funcții de structură D DNTHAL CALLBACKS D dContextCreate, D dContextDestroy, D dContextDestroyAll, D dSceneCapture, D dTextureCreate, D dTextureDestroy, D dTextureSwap, D dTextureGetSurf D DNTHAL CALLBACKS D dClear , D dValidateTextureStageState, D dDrawPrimițives Chiar și cu o scurtă introducere în interfețele GDI DDI și DirectDraw/Direct D DDI, devine evident că acestea au arhitecturi complet diferite Cele mai fundamentale diferențe sunt enumerate mai jos A Interfața GDI DDI funcționează la un nivel mai primitiv decât Direct-Draw/Direct D DDI Prin urmare, motorul grafic trebuie să facă multă muncă preliminară înainte de a accesa interfața GDI DDI, în timp ce calea DirectDraw/Direct D care duce de la API-ul Win este mai simplă și mai directă A În suportul GDI DDI, driverul de afișare poate obține oricând ajutor de la motorul grafic, returnând apelul primit la acesta În Direct-Draw/Direct D DDI, emularea software se face într-un DLL client în modul utilizator, astfel încât driverul de ecran nu poate profita de stratul de driver în modul kernel A Interfața GDI DDI folosește o modalitate simplă și ușor extensibilă de a obține informații despre funcțiile driver indirecte, în timp ce DirectDraw/Direct D DDI descrie funcțiile indirecte ca o serie de structuri de date Așadar, ne-am uitat la modul de inițializare a unui driver de ecran pentru a suporta GDI, DirectDraw și Direct D și chiar am învățat puțin despre punctele de intrare principale și funcțiile de apel indirect al driverului Vom reveni la acest subiect și vom vedea cum aceste funcții indirecte sunt utilizate de motorul grafic pentru a explora structurile interne de date ale sistemului grafic Windows (Capitolul ) și pentru a monitoriza GDI/DirectDraw (Capitolul ) Drivere de imprimantă Driverul de afișare descris în secțiunea anterioară este doar una dintre clasele de drivere pentru dispozitive grafice acceptate de sistemul de operare O altă clasă importantă de drivere pentru dispozitive grafice controlează funcționarea dispozitivelor de copiere pe hârtie - imprimante, plotere, faxuri etc Driverele pentru aceste dispozitive grafice au aceeași structură, așa că tot ce se va spune despre driverul de imprimantă, în principiu, se aplică și pentru driverul de fax În funcție de tehnologia de ieșire, dispozitivele de copiere pe hârtie sunt împărțite în trei clase A Dispozitivele de text sunt dispozitive tradiționale de imprimare în linie capabile să producă numai text simplu Într-un mediu orientat pe GUI Windows în modul WYSIWYG, se întâlnesc Capitolul Arhitectura grafică Windows este destul de rar Driverul de dispozitiv trimite un flux de text cu formatare minimă (întreruperi de linie și de pagină) către dispozitivul de text A Dispozitive raster - Această categorie include imprimantele cu matrice de puncte, aparatele de fax și majoritatea imprimantelor cu jet de cerneală Driverul de dispozitiv trebuie să poată converti comenzile grafice DDI într-un bitmap și să le codeze în limbajul imprimantei (PCL , ESC/ etc ) A Dispozitive Vector - imprimante laser, plotere, imprimante PostScript și unele modele Deskjet moderne În timp ce unele dintre aceste dispozitive imprimă direct în modul raster, toate acceptă introducerea în format vectorial, iar conversia raster este realizată de imprimanta însăși Un driver de dispozitiv vectorial traduce de obicei comenzile grafice DDI în comenzi ale limbajului de imprimantă, cum ar fi PCL , PCL , HPGL, HPGL/ sau PostScript Dispozitivele vectoriale acceptă de obicei date raster în plus față de datele vectoriale Driverul complet de imprimantă pentru Windows NT/ constă din mai multe componente, dintre care doar primele două sunt necesare: Despre ieșirea grafică DLL, care (precum driverul de ecran) primește comenzi grafice DDI, le traduce în limbajul imprimantei și trimite datele către spooler; O interfață DLL care oferă o interfață de utilizator pentru opțiunile de configurare a imprimantei și un spooler pentru a controla instalarea, configurarea și raportarea erorilor; O Procesorul de imprimare opțional ajută spoolerul să trimită lucrări de imprimare; O Monitorul opțional de limbă oferă comunicare bidirecțională între spooler și utilizator; O Monitorul opțional de porturi transmite date pregătite pentru imprimare către driverele de porturi hardware Drivere Microsoft pentru controlul imprimantei Microsoft a creat mai multe drivere standard pe care producătorii de imprimante le pot folosi pentru a conecta drivere personalizate ca module (în loc să dezvolte drivere cu drepturi depline) A Driverul de imprimantă universal (Unidrv) este proiectat pentru imprimante non-PostScript, cum ar fi imprimantele cu matrice de puncte, Deskjet și Laserjet Producătorul imprimantei poate furniza doar un mini-driver pentru Unidrv, care în forma sa minimă este un fișier text GPD care descrie capacitățile imprimantei, parametrii, restricțiile condiționate și comenzile imprimantei Arhitectura Unidrv permite utilizarea plug-in-urilor Modulul de randare oferă procesare non-standard a comenzilor grafice, transformări în tonuri de gri și construirea de date gata de transfer la o imprimantă Modulul de interfață cu utilizatorul vă permite să personalizați paginile de proprietăți ale imprimantei, structura DEVMODE și procesul de gestionare a evenimentelor de tipărire Drivere de imprimantă A Driverul de imprimantă PostScript (Pscript) este pentru imprimante PostScript Mini-driverul PostScript constă dintr-un fișier text PPD care descrie caracteristicile imprimantei, un fișier NTF binar care descrie fonturile imprimantei, un modul de randare și un modul de interfață cu utilizatorul A Driverul pentru plotter este un standard Microsoft pentru suportarea ploterelor compatibile cu HPGL/ (Hewlett-Packard Graphics Language) Driverul Mini Plotter este un fișier PCD binar care descrie caracteristicile plotterului Modulele nu sunt create pentru acesta, deoarece limbajul HPGL/ are o structură destul de rigidă Windows DDK conține codul sursă complet al driverului de plotter de la Microsoft Driverele standard Microsoft folosesc o arhitectură foarte interesantă bazată pe date Aceste drivere acceptă mii de modele diferite de imprimante de pe piață, iar diferențele dintre ele sunt adesea reduse la mici diferențe în fișierele de date Fișierul GPD al driverului Unidrv descrie orientarea hârtiei, tava de alimentare, dimensiunea hârtiei, rezoluția, modul de imprimare, tipul suportului, modul culoare, calitatea imprimării, conversiile în tonuri de gri, restricțiile de configurare, comenzile de configurare a imprimantei și comenzile de imprimare în detaliu Se întâmplă adesea ca atunci când este lansat un nou model de imprimantă, producătorul trebuie doar să actualizeze fișierul GPD și să îi adauge informații despre noul mod de imprimare cu rezoluție mai mare Fișierele GPD sunt scrise într-un limbaj destul de expresiv, cu suport pentru cele mai simple tipuri de date (numere întregi, perechi, șiruri și liste) și chiar variabile cu comenzi de selecție Totuși, mă întreb de ce Microsoft nu a folosit limbaje standard precum Lisp sau Prolog, care sunt mai puternice și mai ușor de procesat? DLL de grafică a driverului de imprimantă DLL-ul grafic al driverului de imprimantă este foarte asemănător cu driverul de afișare discutat în secțiunea Drivere de afișare Principala diferență este că driverul de imprimantă trebuie să ofere puncte de intrare suplimentare pentru a gestiona documentele și paginarea, dar nu are nevoie de puncte de intrare pentru a suporta cursorul mouse-ului, DirectDraw și Direct D Desigur, driverul de imprimantă trebuie să suporte funcțiile de bază responsabile de inițializarea driverelor de dispozitive grafice, și anume DrvEnableDriver, DrvEnablePDEV, DrvCompletePDEV, DrvDi sabl ePDEV, DrvEnableSurface, DrvDisableSurface și, în final, DrvDi sabl eDriver Driverul de imprimantă trebuie să ofere, de asemenea, paginare și interogări specifice imprimantei În tabel Tabelul listează puncte de intrare suplimentare care trebuie sau pot fi acceptate de imprimantă Driverele de imprimantă Windows au o caracteristică interesantă - ele pot exista nu numai ca DLL-uri în modul kernel, ci și ca DLL-uri de utilizator Microsoft depune eforturi deosebite pentru a scoate driverele de imprimantă din spațiul de adrese kernel în spațiul de adrese ale utilizatorului Dar rețineți că driverul de imprimantă poate importa funcții ale motorului grafic win k sys care nu sunt disponibile la nivel GDI Pentru a rezolva asta Capitolul Arhitectura grafică Windows Probleme Windows GDI exportă un subset de funcții ale motorului grafic, astfel încât un driver de imprimantă în modul utilizator să poată lucra direct cu acestea Motorul grafic transmite în mod special apelurile către driverul de imprimantă din modul kernel în modul utilizator, după care GDI traduce apelurile către motor de la driver din modul utilizator înapoi în modul kernel Driverele de imprimantă în modul utilizator oferă o serie de beneficii, inclusiv costuri de dezvoltare mai mici, flexibilitate sporită în API-urile Win utilizate și, mai important, modificarea redusă a nucleului Dacă driverul de imprimantă rulează în modul utilizator, DLL-ul driverului trebuie să exporte funcțiile DrvEnableDriver, DrvDisableDriver și DrvQueryDriver, iar funcția DrvQueryDriverInfo trebuie să returneze informațiile corespunzătoare atunci când procesează o solicitare DRVQUERY USERMODE Toate driverele standard de imprimantă Microsoft Windows sunt drivere de imprimantă în modul utilizator Tabelul Puncte de intrare dedicate driverului de imprimantă Punctul de intrare Scop DrvQueryDriverInfo (opțional) Interpretarea interogării depinde de driver Folosit în prezent pentru a obține informații de la driverele pentru modul utilizator DrvQueryDevi ceSupport (Opțional) Interpretarea interogărilor depinde de dispozitiv Utilizat în prezent pentru cererile de asistență JPEG și PNG DrvStartDoc Spune șoferului că GDI este gata să transfere documentul DrvEndDoc informează șoferul că transferul documentului a fost finalizat DrvStartPage Spune driverului că GDI este gata să trimită comenzi grafice către o pagină nouă DrvSendPage informează șoferul că transferul comenzilor paginii grafice este complet - driverul poate trimite datele procesate către spooler DrvStartBanding Întrebarea șoferului unde pe pagină ar trebui să înceapă bandarea DrvQueryPerBandInfo (opțional) Interogați driverul pentru o structură PERBANDINFO cu informații despre dimensiunea și rezoluția benzii DrvNextBand (opțional) informează șoferul că transferul comenzilor benzii grafice este complet - șoferul poate transfera datele procesate în spooler Punctul principal de intrare al driverului de imprimantă este în continuare DrvEnable-Printer Când o aplicație apelează CreateDC pentru a crea un context de dispozitiv pentru o imprimantă, motorul grafic verifică dacă driverul de imprimantă este încărcat Dacă driverul nu este încărcat, acesta este încărcat, după care este apelată funcția DrvEnableDriver Drivere de imprimantă Funcția DrvEnablePDEV a driverului de imprimantă este apelată de motorul grafic atunci când o aplicație apelează funcția CreateDC pentru imprimantă În comparație cu driverul de afișare, această funcție este mai complexă deoarece trebuie să țină cont de numeroasele opțiuni de imprimare trecute în structura DEVMODE În special, driverul trebuie să ajusteze rezoluția de ieșire în funcție de calitatea de imprimare selectată, să schimbe dimensiunile hârtiei pentru modul peisaj (peisaj), să calculeze dimensiunile zonei de ieșire pe baza dimensiunii hârtiei și să transmită informații despre margine Alte opțiuni de imprimare pot fi trecute în structura DEVMODE, cum ar fi modul duplex, colaţionare, numărul de copii, pagini pe coală și opțiuni specializate oferite de alte componente ale sistemului de imprimare De exemplu, în Windows , imprimarea duplex, colaţionarea, imprimarea mai multor copii şi imprimarea pe mai multe pagini sunt implementate de motorul de imprimare standard Windows , astfel încât driverul de imprimantă de bază trebuie să scoată doar o singură pagină Un driver de imprimantă raster poate crea o suprafață condusă de motorul grafic atunci când apelează DrvEnableSurface și apoi poate solicita motorului grafic să efectueze toată (sau cea mai mare parte) rezultate Cu toate acestea, există o problemă cu aceasta - imprimanta funcționează la o rezoluție mult mai mare decât ecranul monitorului, astfel încât redarea întregii pagini în același timp va necesita un consum excesiv de memorie De exemplu, o pagină cu dimensiunea unei litere la x dpi are x x , x pixeli sau aproximativ megapixeli Când imprimați într-o singură culoare la dpi, un raster de pagină ocupă aproximativ megaoctet, iar atunci când este imprimat pe o imprimantă color cu o rezoluție de dpi și culoare pe de biți, dimensiunea rasterului paginii se apropie de de megaocteți Pentru a menține costul uriaș al memoriei la un nivel rezonabil, motorul grafic vă permite să împărțiți pagina în dungi orizontale Împărțirea unei pagini de dimensiunea unei litere în benzi egale de inch reduce de megaocteți la , megaocteți În acest caz, șoferul trebuie să folosească funcția EngMarkBandingSurface pentru a informa motorul grafic că suprafața este redată folosind staking O imprimantă vectorială nu trebuie să redeze întreaga pagină simultan ca raster; în schimb, traduce în serie comenzile grafice DDI în comenzi pentru imprimantă De obicei, este creată o suprafață condusă de dispozitiv, iar driverul interceptează comenzile grafice DDI Pe imprimantele vectoriale, divizarea nu este de obicei aplicată După ce driverul este încărcat și sunt create structurile de date pentru dispozitivul fizic și suprafața, GDI, asistat de motorul grafic, transmite întregul document driverului de imprimantă Procesul de retragere arată cam așa: DrvStartDoc(DocName Jobld) pentru (Int = ; "): Write(index Pair DDIFunction); // Numele funcției este preluat din tabel ScrieCC): const unsigned * pDWORD = (const unsigned *) firstpara: for (int i= ; i "); Funcția KDevice::Caii Engine verifică indicatorul către KDevice; dacă pointerul este non-NULL, apelează funcția LogCal Funcția Caii Engine este apelată de toate funcțiile grafice ale driverului DDI înainte de a returna apelul către motorul grafic Astfel, implementarea Caii Engine poate bloca selectiv unele funcții DDI pentru a forța motorul grafic să le descompună în apeluri simplificate Interfața driverului DDI este implementată în fișierul HTMLDrv cpp Fișierul începe cu un tabel de puncte de intrare acceptate: const DRVFN DDI Funcs[] = { INDEXJDrvEnablePDEV INDEX DrvCompletePDEV, INDEXJDrvResetPDEV INDEX DrvDisablePDEV, INDEX DrvEnableSurface, INDEX DrvDisableSurface (PFN) DrvEnablePDEV (PFN) DrvCompletePDEV, (PFN) DrvResetPDEV (PFN) DrvDisablePDEV (PFN) DrvEnableSurface, (PFN) DrvDisableSurface INDEX DrvStartDoc INDEX DrvEndDoc INDEX DrvStartPage INDEX-DrvSendPage (PFN) DrvStartDoc (PFN) DrvEndDoc (PFN) DrvStartPage (PFN) DrvSendPage INDEXJDrvStrokePath (PFN) DrvStrokePath INDEX DrvFi Cale (PFN) DrvFi Path INDEX DrvStrokeAndFi Path,(PFN) DrvStrokeAndFi Path INDEX DrvLineTo, (PFN) DrvLineTo, INDEX DrvPaint (PFN) DrvPaint INDEX DrvBitBlt (PFN) DrvBitBlt INDEX DrvCopyBits, (PFN) DrvCopyBits Capitolul Arhitectura grafică Windows INDEX DrvStretchBlt, (PFN) DrvStretchBlt, INDEX-DrvTextOut (PFN) DrvTextOut }: Funcția DrvEnableDriver, după o simplă verificare, transmite tabelul de funcții motorului grafic: BOOL APIENTRY DrvEnableDriver(ULONG EngineVersion, ULONG cj DRVENABLEDATA *pded) { // Verificați parametrii dacă (iEngineVersion iDriverVersion = DDI DRIVER VERSION: pded->c = sizeof(DDI Hooks) / sizeof(DDI Hooks[OJ); pded->pdrvfn = (DRVFN *) DDI Hooks; returnează TRUE: } Mai jos este o parte a funcției DrvEnablePDEV care creează o nouă instanță a clasei KDevice Această funcție scrie informații despre capacitatea driverului în structurile GDIINFO și DEVINFO în funcție de valorile câmpurilor din structura DEVMODW primită În acest caz, programul verifică orientarea hârtiei DHPDEV APIENTRY DrvEnablePDEV(DEVMODEW *pdm LPWSTR pwszLogAddress ULONG cPat, HSURF *phsurfPatterns ULONG cjCaps ULONG *pdevcaps ULONG cjDevInfo DEVINFO *pdi HDEV hdev PWSTR pwszDeviceName MÂNĂRĂ hDriver) { dacă ( (cjCaps Creare(); pDevice->hSpooler = hDriver; pDevice->hPalette = EngCreatePalette(PAL BGR, , , , , ): Dacă (pdm == NULL || pdm->dmOrientation == DMORIENT PORTRAIT) { pDevice->width = PaperWidth; pDevice->height = PaperHelght; } el se { pDevice->width = PaperHelght; pDevice->height = PaperWidth; } // Inițializarea GDIINFO a fost omisă // Inițializarea DEVINFO a fost omisă pdi->hpalDefault = pDevice->hPalette; returnare (DHPDEV) pDispozitiv; } Funcția DrvEnableSurface creează o suprafață DIB pe de biți gestionată de GDI și îi spune motorului grafic că driverul dorește să intercepteze unele apeluri DDI Rețineți că dimensiunile hârtiei sunt specificate în zecimi de inch pentru a evita operațiunile cu virgulă mobilă în nucleu Suprafața este inițializată cu culoarea albă nu la creare, ci la apelarea DrvStartPage HSURF APIENTRY DrvEnableSurface(DHPDEV dhpdev) { KDevice * pDevice = (KDevice *) dhpdev; DIMENSIUNE sizl = { pDevice->width * Dpi / , pDevice->height * Dpi / }; pDevice->hSurface = (HSURF) EngCreateBitmap(sizl, sizl cy, BMF BPP, BMF NOZEROINIT, NULL); dacă (pDevice->hSurface == NULL) returnează NULL; EngAssociateSurface(pDevice->hSurface, pDevice->hDevice, HOOK BITBLT | HOOKJTRETCHBLT | HOOKJEXTOUT | HOOK PAINT | HOOK STROKEPATH | CÂRLIG FILLCATH | HOOK STROKEANDFILLPATH | HOOK COPYBITS | HOOK LINETO); returnează pDevice->hSurface; Capitolul Arhitectura grafică Windows Deși driverul HTML interceptează unele dintre funcțiile grafice, întreaga implementare se rezumă la simpla afișare a informațiilor despre parametri, după care apelul este returnat motorului grafic Următorul este doar un exemplu tipic care oferă o idee despre alte implementări Primul parametru al tuturor apelurilor DDI grafice este un pointer către SURFOBJ, structura de date folosită de motorul grafic pentru a reprezenta suprafața de ieșire Câmpul dhpdev conține mânerul fizic al dispozitivului furnizat de driver și returnat de funcția DrvEnable ePDEV În acest caz, manipulatorul este convertit într-un pointer către un KDevice BOOL APIENTRY DrvBitBltCSURFOBJ *psoTrg, SURFOBJ *psoSrc, SURFOBJ *psoMask, CLIPOBJ*pco, XLATEOBJ*pxlo, RECTL *prclTrg, POINTL*pptlSrc, POINTL*pptlMask, BRUSHOBJ*pbo, POINTL *pptlBrush R P rop ) { KDevice * pDevice = (KDevice *) psoTrg->dhpdev: if ( pDevice->CallEngine(INDEX DrvBitBlt, &psoTrg, ) ) return EngBitBltCpsoTrg, psoSrc, psoMask, pco, pxlo, prclTrg, pptlSrc, pptlMask, pbo, pptlBrush, rop ): el se returnează FALSE; } Așa arată cele mai interesante componente ale driverului HTML Următoarea este o versiune prescurtată a rezultatelor obținute la tipărirea unei pagini de test standard Într-un browser web, arată destul de decent (fig ) Pagina de testare DrvStartDoc(e , ele ) DrvSta rtPage(e ) DrvFillPath(e , fld fa l) DrvBitBlt(e , , fld f b fOfO) DrvText ut(e , fld f dOd) DrvText ut(e , fld f dOd) DrvSendPage(e ) DrvEndDoc(e ) Rezultate DrvTextOut(el e , fb , e dO , fb c, , fb , e cc, e , e c, dOd) DrvSendPagefe e ) Wnctowexoo Windows Pagina de testare a imprimantei Orez Pagina de testare în browser După cum puteți vedea, driverul de imprimantă simplificat (sau mai degrabă, DLL-ul său grafic) nu este complicat Ar putea fi simplificată și mai mult prin refuzul de a ieși parametrii Un driver de imprimantă real este mult mai complex Dacă doriți să vedeți acest lucru, vă rugăm să consultați exemplul de driver pentru plotter din Microsoft Windows DDK sau driverul PostScript din Windows NT DDK Cu toate acestea, un driver de imprimantă cu drepturi depline, de înaltă calitate și optimizat este mai complex decât exemplele incluse în DDK Rezultate În acest capitol, am analizat arhitectura generală a sistemului grafic Windows, arhitectura Win GDI client-side, arhitectura DirectX și arhitectura sistemului de imprimare și am cunoscut motorul grafic, driverele de afișare și driverele de imprimantă A fost creat un program pentru a urmări apelurile grafice de sistem atât pe partea client, cât și pe server Capitolul se încheie cu o descriere a unui driver de imprimantă simplu care generează date în format HTML Principalul lucru pe care cititorul ar trebui să-l ia din acest capitol sunt diagramele bloc care descriu diferitele niveluri ale arhitecturii sistemului grafic Ar trebui să aveți o idee generală despre ce aspecte ale sistemului grafic Windows NT/ sunt deservite de o anumită componentă a sistemului și despre modul în care apelurile la funcțiile grafice Win API sunt implementate de diferitele componente din lanțul de procesare Deși acest capitol s-a ocupat de probleme generale de arhitectură, iar materialul a fost însoțit de diagrame de flux, atât de displacute de mulți programatori, ceea ce urmează va fi mai specific În capitolul , vom explora subdocu- Capitolul Arhitectura grafică Windows structuri de date montate pe care se bazează GDI și DirectDraw, apoi vom trece la capitolul mai interesant și ne vom familiariza cu structura din culise a sistemului grafic Exemple de programe CD-ul însoțitor conține codul sursă complet pentru programele descrise în acest capitol (Tabelul ) Tabelul Capitolul Programe Descriere director de proiect Samples\Chapt \SysCall Afișarea listei de funcții ale sistemului DLL subsistemului Win (ntdll dll, gdi dll și user dll) și funcțiilor sistemului kernel-ului OS (ntoskrnl exe, win k sys) Samples\Chapt \Timer Analiza comparativă a patru metode de sincronizare: GetTickCount, timeGetTime, QueryPerformanceCounter și citirea contorului de cicluri al procesorului Intel Pentium Driver de imprimantă Samples\Chapt \HTMLDrv (redarea paginilor HTML, înregistrarea comenzilor DDI și redarea paginilor pe un bitmap încorporat) Capitolul Structuri interne de date GDI/DirectDraw API-ul Windows este adesea numit „obiect-based” (object ba-sed) - nu confundați cu „object-oriented” (orientat pe obiect), acestea nu sunt același lucru Când utilizați API-ul Win , de multe ori trebuie să creați diverse obiecte, să efectuați diferite operații asupra lor folosind funcții și, în cele din urmă, să le distrugeți Sistemul de operare controlează complet reprezentarea internă a obiectului, iar programatorul are doar un manipulator (mâner) la dispoziția programatorului GDI folosește zeci de obiecte diferite - contexte de dispozitiv, pixuri logice, pensule logice, fonturi logice, palete logice, hărți de biți independente de dispozitiv, secțiuni DIB etc Dar pentru orice obiect, ai de-a face doar cu un manipulator - un număr misterios, cu la care nu se poate face nimic (cu exceptia trecerii la apelarea functiei GDI) Acest capitol descrie manipulatorii GDI în detaliu și, mai important, structurile de date din spatele lor Veți afla ce înseamnă fiecare bit dintr-un mâner GDI, cum este mapat un mâner la o intrare dintr-un tabel de obiecte GDI și chiar veți afla despre structurile de date utilizate în reprezentarea internă a tuturor obiectelor GDI În plus, acest capitol discută structurile de date DirectDraw Cu ajutorul bunului simț, tehnici de „hack”, utilități de la Microsoft și câteva programe scrise special pentru acest capitol, vom atinge scopul principal - înțelegerea structurilor cheie de date ale GDI/DirectDraw Este posibil să nu fiți prea interesat de detaliile tehnice ale structurilor de date GDI Cu toate acestea, cunoașterea elementelor interne generale ale GDI/DirectDraw vă va îmbunătăți abilitățile de programare Windows Acest capitol acoperă și câteva trucuri utile - de exemplu, vizualizarea conținutului memoriei virtuale, scrierea unui driver Capitolul Structuri interne de date GDI/DirectDraw dispozitive în modul kernel (nu, nu pentru imprimantă!) și instalarea extensiei de depanare WinDbg pentru a explora nucleul NT/ pe aceeași mașină Manipulatoare și programare orientată pe obiecte În limbajele și mediile orientate pe obiecte, un obiect este o colecție de date și funcții care modelează o entitate în lumea reală sau imaginară Obiectele sunt împărțite în clase în funcție de caracteristicile lor comune De regulă, în limbajele orientate pe obiecte, definițiile de clasă sunt cele care ocupă centrul; un obiect este doar o instanță a unei clase create în timp ce programul rulează API-ul Win definește, de asemenea, diferite tipuri de obiecte Cele mai comune obiecte GDI sunt contextele dispozitivului, pixurile logice, pensulele logice, fonturile logice, paletele logice și hărțile de biți specifice dispozitivului Astfel, toate obiectele de context dispozitiv sunt instanțe ale clasei de context de dispozitiv și toate paletele logice sunt instanțe ale clasei paletei logice clasa si obiectul Clasele din limbaje orientate pe obiecte conțin atât date (variabile de clasă), cât și cod de program (funcții de clasă) Accesul la membrii clasei (adică variabilele și funcțiile acesteia) este controlat de definiția clasei Unii membri ai clasei sunt declarați privați (privati) și protejați (protejați), în timp ce alții sunt publici (publici) Când se creează o instanță a unei clase, memoria este alocată mai întâi și apoi este apelat constructorul Utilizarea membrilor clasei private și protejate vă permite să izolați implementarea internă a clasei de codul programului care utilizează această clasă Conceptele de încapsulare și mascarea implementării sunt pietrele de temelie ale programării orientate pe obiecte În API-ul Win , implementarea unor clase este, de asemenea, bine încapsulată la nivel de sistem După cum se va arăta mai târziu, obiectele conțin întotdeauna variabile – de obicei organizate într-o structură de date sau chiar într-o rețea ierarhică complexă de structuri Fiecare clasă definește un set standard de funcții care se aplică obiectelor din acea clasă De exemplu, un context de dispozitiv este un obiect GDI, o instanță a unei clase de context de dispozitiv Această clasă definește funcții precum GetSetColor și SetTextColor pentru a obține/seta culoarea textului Instinctul programatorului este că culoarea textului este o variabilă de clasă asociată cu obiectul context al dispozitivului, dar nu avem idee unde sau în ce reprezentare internă este stocată Cu alte cuvinte, implementarea internă a unui context de dispozitiv este complet ascunsă de programatorii de aplicații Manipulatoare și programare orientată pe obiecte Mascare de încapsulare și implementare În practica obișnuită de programare orientată pe obiecte, unii membri ai unei clase sunt declarați privați sau protejați și nu pot fi utilizați de codul clientului Cu toate acestea, compilatorul trebuie să cunoască exact toți membrii clasei, tipurile și numele acestora Cel puțin, compilatorul trebuie să cunoască dimensiunea exactă a instanței de clasă pentru a aloca memorie Acest lucru poate cauza o mulțime de probleme în programarea modulară De fiecare dată când o variabilă sau o funcție se schimbă într-o clasă, întregul program trebuie să fie recompilat Programele compilate pentru versiunile mai vechi ale definiției clasei nu vor funcționa cu versiunile mai noi Clasele de bază abstracte sunt create pentru a rezolva această problemă O clasă de bază abstractă, folosind funcții virtuale, definește o interfață cu programele client, abstragând complet de la implementarea acesteia, ceea ce ajută la mascarea implementării și la îmbunătățirea modularității programului O manifestare extremă a mascării implementării sunt interfețele COM, care sunt clase fără variabile, constând doar din funcții virtuale pure O clasă care conține o funcție virtuală pură nu poate fi folosită pentru a crea obiecte Programatorul trebuie să creeze o clasă derivată pe baza acesteia, să implementeze toate funcțiile pur virtuale și să creeze o instanță a clasei derivate Pentru a masca clasa derivată de la client, este creată o funcție statică specială pentru a crea obiecte De exemplu, DLL-urile COM exportă întotdeauna funcția DIIGetClassObject, care (cu asistența unei fabrici de clase) este responsabilă pentru crearea de noi obiecte suportate de DLL-ul COM Pentru a masca implementarea din partea client a clasei, de obicei este definită o funcție specială care creează instanțe ale clasei derivate și le alocă memorie și o altă funcție care distruge instanțele și eliberează memoria alocată Obiectele API Win pot fi considerate ca fiind implementate folosind o clasă de bază abstractă care nu conține variabile Reprezentarea internă a datelor unui obiect este complet ascunsă de aplicația utilizator Beneficiile acestei abordări sunt enorme; un program compilat pentru Win s (un subset al API-ului Win implementat în Windows ) rulează impecabil pe Windows , în timp ce un program compilat pentru Windows funcționează bine pe Windows NT și Windows Programele binare Win sunt compatibile cu diferite versiuni de sisteme de operare sisteme care implementează API-ul Win pe un singur tip de procesor Deși posibilitățile de utilizare a unui singur API Win nu sunt nelimitate, un subset semnificativ de API-uri Win sunt implementate pe platforme diferite cu aceeași semantică În ceea ce privește GDI, implementarea acestei interfețe pentru Windows / se bazează în mare parte pe implementarea sa pe biți pentru Windows ; în Windows NT , GDI funcționează ca un proces de sistem separat care rulează în modul utilizator, în timp ce în Windows NT și Windows , este utilizat un motor grafic pe de biți în modul kernel Există diferențe notabile între aceste implementări, dar acoperirea lor impecabilă în API-ul Win asigură portabilitatea programului GDI de obicei Capitolul Structuri interne de date GDI/DirectDraw suportă mai multe funcții pentru instanțierea unui obiect și mai multe funcții pentru distrugerea acestuia Pentru a demonstra analogia dintre programarea orientată pe obiecte și API-ul Win , să încercăm să scriem o pseudo-implementare minimă a GDI în C++ Rezultatul este prezentat în Lista Lista Pseudo-implementare a GDI în C++ // gdi h clasa GdiObj { public: virtual int GetObjectType(void) = : virtual int GetObject(int cbBuffer void * pBuffer) = ; virtual bool DeleteObject(void) = : virtual bool UnrealizeObject(void) = : clasa Pen : public GdiObj { public: virtual int GetObjectType(void) returnează OBJ PEN; } virtual int GetObject(int cbBuffer, void * pBuffer) = : virtual bool DeleteObject(void) = : virtual bool UnrealizeObject(void) { returnează adevărat: } }; Pen * CreatePen(int fnPenStyle, int nWidth, COLORREF crColor): // gdi cpp #define STRICT #define WIN LEAN AND MEAN #include #include „gdi h” clasa RealPen : Pen public { LOGPEN m LogPen: public: RealPen(int fnPenStyle, int nWidth COLORREF crColor) { m LogPen lopnStyle = fnPenStyle: m LogPen lopnWidth x = nWidth: m LogPen lopnWidth y = : Manipulatoare și programare orientată pe obiecte m LogPen opnColor = crColor; } int GetObjectdnt cbBuffer, void * pBuffer) { Dacă ( pBuffer==NULL ) returnează dimensiunea(LOGPEN): el se if ( cbBuffer>=sizeof(m LogPen) ) { memcpy(pBuffer, & m LogPen, sizeof(m LogPen)): returnează sizeof(LOGPEN); } el se { SetLastError(ERROR INVALID PARAMETER): returnează ; } } bool DeleteObject(void) { daca (acesta) { șterge asta; returnează adevărat; } el se returnează fals; } Pen * CreatePen(int fnPenStyle int nWidth COLORREF crColor) { returnează RealPen nou (fnPenStyle nWidth, crColor): } void Test (gol) { Pen * pPen = CreatePen(PS SOLID, RGB( , , OxFF)); //// pPen->DeleteObject(); } Lista definește o clasă de bază abstractă, GdiObj, care reprezintă un obiect GDI generic Este format din patru funcții virtuale pure și nu conține nicio variabilă Clasa generică de stilouri Rep este definită pentru a deriva din GdiObj; implementează două funcții virtuale și le lasă pe celelalte două pur virtuale Funcția CreatePen creează instanțe ale clasei Rep Fișierul de implementare (GDLcpp) definește o clasă de stilouri reale (RealPen) care stochează informații despre stilou într-o structură LOGPEN Clasa Real Rep este o implementare completă a clasei Rep abstracte cu un constructor și celelalte două funcții virtuale Funcția CreatePen Capitolul Structuri interne de date GDI/DirectDraw creează o instanță a clasei Real Rep și transmite un pointer către aceasta în loc de un pointer către clasa generică de stilouri Rep Partea client nu știe câtă memorie ocupă obiectul stilou, de unde este alocată acea memorie și cum sunt implementate funcțiile virtuale Toate aceste detalii rămân ascunse Partea client trebuie doar să cunoască numele metodelor de interfață, scopul și semantica acestora Indicatori și manipulatoare Când creați un obiect într-un limbaj orientat pe obiecte, trebuie să alocați un bloc de memorie pentru a stoca variabilele obiectului Dacă clasa conține funcții virtuale, un pointer suplimentar către un tabel cu toate implementările funcțiilor virtuale ale acestei clase este creat împreună cu variabilele din memorie În limbaje precum C++, pointerii către obiecte sunt centrale Pointerii sunt transferați către toate funcțiile non-statice ale clasei, ceea ce vă permite să accesați variabilele obiectului și să apelați funcțiile virtuale necesare În C++, un pointer către obiectul curent este notat cu cuvântul cheie this Figura , folosind exemplul clasei RealPen (vezi Lista ), arată la ce se referă exact pointerul obiectului În clasa Real Rep, sunt necesari octeți pentru a stoca singura variabilă de clasă, m LogPen, și alți octeți pentru un pointer către tabelul de funcții virtuale Prin urmare, pentru fiecare obiect trebuie alocați minim de octeți Pointerul către tabelul de funcții virtuale se referă la un bloc de patru pointeri de funcție În exemplul de mai sus, două funcții sunt implementate de clasa Pen, iar celelalte două de clasa RealPen Tabel de funcții virtuale pentru clasa RealPen Class O instanță de Knacca RealPen Indicator^ către un obiect Indicator către tabelul de funcții virtuale LOGPEN lopnStyle lopnWidth lopnColor & Pen::GetObjectType & Real Rep ::GetObject &-RealPen::DeleteObject & Pen::UnrealizeObject Orez Un exemplu de reprezentare a unui obiect în C++ În COM, un pointer către un obiect este de obicei numit indicator de interfață și se referă la un pointer către un tabel de funcții În exemplul de mai sus, funcția CreatePen creează o instanță de Real Rep, dar returnează un pointer la clasa Rep Ca și în COM, codul clientului nu știe nimic despre reprezentarea internă a datelor Deși API-ul Win alocă un bloc de date pentru fiecare obiect undeva în memorie, dezvoltatorii Microsoft nu au returnat un pointer către acesta în aplicația utilizatorului Poate că acest lucru a fost făcut din cauza faptului că pointerul transportă prea multe informații pentru programatorii „inteligenti” - oferă locația exactă a obiectului în memorie Indicatoarele vă permit Manipulatoare și programare orientată pe obiecte Acceptați operațiuni de citire/scriere pe reprezentarea internă a obiectelor pe care sistemul de operare ar prefera să le ascundă de utilizator În plus, pointerii fac dificilă partajarea obiectelor din spațiile de adrese ale diferitelor procese Pentru a ascunde aceste informații de programatori, funcțiile de creare a obiectelor Win returnează de obicei mânerul obiectului în loc de un pointer Un manipulator este definit ca un număr care identifică în mod unic un obiect și poate fi folosit pentru a-l referi indirect Relația obiectelor cu manipulatoarele nu este documentată, imuabilitatea acesteia în versiunile viitoare de Windows nu este garantată și, în general, toate detaliile sunt cunoscute doar de Microsoft și chiar de mai mulți producători de utilități de sistem Se poate considera că maparea pointerilor către obiecte către manipulatoare și invers este realizată de două funcții Codificare și Decodare, prototipurile cărora sunt prezentate mai jos HANDLE Encode(vo d * pObject); // Convertiți indicatorul în handle void * Decode(HANDLE hObject): // Convertiți handlerul în pointer Afișarea identității Uneori, valoarea manipulatorului poate fi aceeași cu valoarea indicatorului de obiect; în acest caz, funcțiile Codificare și Decodare sunt limitate la conversia tipului, iar relația dintre pointerii obiect și manipulatori este identică În API-ul Win , un mâner de instanță (HINSTANCE) sau un mâner de modul (HMODULE) este pur și simplu un pointer către o imagine de fișier PE mapată în memorie Funcția LockResource ar trebui să blocheze resursa în memorie și să mapeze mânerul global la pointer, dar în realitate valorile lor sunt aceleași Mânerul de resurse returnat de funcția Load-Resource este de fapt un pointer de resursă mapat de memorie deghizat Afișaj de masă Cel mai obișnuit mecanism pentru stabilirea unei relații între un obiect și mânerul acestuia este afișarea unui tabel Sistemul de operare construiește un tabel cu toate obiectele utilizate Când este creat un obiect nou, tabelul conține un rând gol, care este umplut cu datele obiectului Când un obiect este șters, variabilele sale sunt șterse din memorie, iar elementul de tabel corespunzător este eliberat pentru utilizare ulterioară Într-o schemă de gestionare a obiectelor de tabel, indicii de tabel sunt candidați buni pentru manipulatori, iar conversia pointerilor în manipulatoare și invers este trivială În Win API, informațiile despre obiectele kernel sunt stocate în tabele la nivel de proces Categoriile de obiecte kernel includ mutexuri, semafore, evenimente, chei de registry, porturi, fișiere, legături simbolice, directoare de obiecte, fișiere mapate în memorie, fire de execuție, desktop-uri, temporizatoare și așa mai departe Pentru a gestiona mai multe obiecte kernel, fiecare obiect îmi creează Capitolul Structuri interne de date GDI/DirectDraw propriul tabel de obiecte kernel Una dintre componentele părții executive a nucleului NT/ este managerul de obiecte, care este conceput pentru a gestiona obiectele nucleului Una dintre funcțiile managerului de obiecte se numește ObReferenceObjectByHandle Conform documentației DDK, această funcție verifică permisiunile pentru mânerul obiectului dat și, dacă accesul este acordat, returnează un pointer la corpul obiectului În esență, această funcție convertește mânerul unui obiect într-un indicator de obiect, cu o verificare suplimentară de securitate Există, de asemenea, un utilitar foarte bun numit HandleEx (disponibil la www sysinternals com) pentru listarea obiectelor kernel pe computerele Windows NT/ Când manipularea nu este suficientă Deși manipulatorii oferă o abstractizare, protecție și mascare aproape perfectă a informațiilor, ele provoacă și multe probleme programatorilor Deoarece API-ul Win este orientat spre manipulator, Microsoft nu documentează reprezentarea internă a obiectelor și nu descrie operațiunile asupra acestora Fără implementări de referință - doar prototipuri de funcție, documentație Microsoft și cărți, al căror material se bazează mai mult sau mai puțin pe documentația Microsoft, sunt la dispoziția programatorului Prima categorie de probleme cu care se confruntă programatorii are legătură cu resursele sistemului Nimeni nu știe ce resurse sunt folosite pentru a crea un obiect și a obține mânerul acestuia, deoarece reprezentarea internă a obiectului este necunoscută Cum ar trebui să procedeze programatorul - pentru a stoca și reutiliza obiectul sau pentru a-l șterge cu prima ocazie? Trei tipuri de raster sunt acceptate în GDI - ce tip ar trebui să aleg pentru a salva resursele sistemului? Principala resursă a unui computer este timpul procesorului Mascarea reprezentării interne de la programator face dificilă evaluarea complexității efectuării unor operații la proiectarea algoritmilor complecși Să presupunem că construiți o regiune complexă folosind GDI; ce complexitate are algoritmul tău - liniar, pătratic, cubic? Mascarea completă a implementării face de asemenea mai dificilă depanarea Dacă după minute de rulare programul tău începe să „alunge gunoiul”, probabil este o scurgere de resurse undeva, dar unde anume și cum să o rezolvi? Dacă sunteți administrator de sistem și sute de aplicații rulează pe sistemul dvs , cum puteți afla sursa problemelor atunci când există o lipsă cronică de resurse de sistem? Se pare că singurul instrument de rezolvare a scurgerilor de resurse este programul BoundsChecker, care folosește instrumente speciale de monitorizare pentru a căuta neconcordanțe la crearea și ștergerea obiectelor Cu toate acestea, cele mai grave probleme apar cu compatibilitatea programelor De ce poate un program să treacă obiecte GDI de la un proces la altul în Windows , dar nu în Windows NT/ ? De ce Windows nu poate gestiona rasterele mari, independente de dispozitiv? Se pare că abstracția API „ideală” în diferite sisteme are o semantică diferită În partea principală a acestui capitol, vom arunca o privire mai atentă asupra manipulatoarelor GDI și vom explora lumea nedocumentată din spatele manipulatoarelor Windows NT/ Înțelegerea manipulatorilor de obiecte GDI Înțelegerea manipulatorilor de obiecte GDI Când creați un obiect GDI, obțineți un control asupra acelui obiect În funcție de tipul de obiect creat, mânerul poate fi de tip HPEN, HBRUSH, HFONT, HDC și așa mai departe Totuși, cel mai comun tip de mâner de obiect GDI este tipul HGDIOBJ Tipul HGDIOBJ este definit ca un pointer către void Definiția tipului HPEN utilizată în timpul compilării se modifică în funcție de starea macrocompilației STRICT Dacă macro-ul este definit, atunci HPEN este definit după cum urmează: struct HPEN { int neutilizat; }; typedef struct HPEN * HPEN; Dacă macrocomanda STRICT nu este definită, atunci definiția HPEN arată astfel: typedef void * MÂNER; typedef MÂNER HPEN; Mai simplu spus, dacă este definit STRICT, HPEN este definit ca un pointer către o structură cu un câmp neutilizat și, dacă nu, ca un pointer către void Compilatorul C/C++ vă permite să treceți un pointer către orice tip în loc de un pointer către void (dar nu invers!) Două indicatoare către diferite tipuri non-void nu sunt interschimbabile Când este definit STRICT, compilatorul emite avertismente atunci când tipurile de manipulatoare ale obiectelor GDI sau ale altor obiecte (să zicem, HWND, HMENU etc ) sunt înlocuite incorect și, fără o definiție STRICT, puteți amesteca în siguranță diferite tipuri de manipulatoare fără a risca un avertisment de compilare De exemplu, atunci când definiți un STRICT, puteți transmite HPEN unei funcții care ia un HGDIOBJ (de exemplu, funcția DeleteObject), dar nu puteți transmite HGDIOBJ unei funcții care ia un HBRUSH (cum ar fi funcția FillRgn) fără mai întâi convertindu-l Această separare clară a diferitelor mânere GDI imită ierarhia de clasă a obiectelor GDI, când de fapt nu există o ierarhie de clasă Numai un mâner poate fi creat pentru fiecare obiect GDI, deci nu puteți crea un alt mâner pentru un obiect prin simpla duplicare De obicei, mânerele de obiect GDI sunt valide numai în cadrul unui anumit proces - cu alte cuvinte, un mâner poate fi folosit numai de procesul care l-a creat Manipulatorii transferați de la alte procese sunt invalidi De regulă, obiectele GDI pot fi create în mai multe moduri diferite și sunt distruse de o singură funcție DeleteObject cu parametrul HGDIOBJ Pe lângă crearea directă a unui obiect, puteți utiliza funcția GetStockObject pentru a obține un handle pentru un obiect GDI pre-creat sau puteți utiliza funcții mai complexe pentru a converti o resursă asociată unui modul într-un obiect GDL (cum ar fi LoadBitmap sau Loadlmage) creați în dvs obiectele GDI necesare Totuși, toate cele de mai sus pot fi găsite în documentația electronică Dorim să învățăm multe mai multe despre gestionatorii de obiecte GDI Detaliile despre modul în care funcționează manevrele Windows NT/ GDI nu au fost niciodată documentate și nu există programe gata făcute care să ne poată simplifica cercetarea Prin urmare, vom scrie propriul nostru program destul de complex Capitolul Structuri interne de date GDI/DirectDraw GDIHandles, a căror fereastră principală este formată din trei pagini cu file Structura, implementarea și utilizarea acestui program vor fi luate în considerare treptat pe măsură ce materialul este prezentat Între timp, aruncați o privire la prima pagină a mânerului Decode GDI, prezentată în Figura Deceniu GDI Mâner | Lccate GDI Handle Table | Deceniu GOI Hancfe Tabel | Csre&tOK: GetStockOb j ect (SYSTEM FIXED FONT) GetStockObject(ВLACK BRUSH) GetStockObject(DKGRAY BRUSH) GetStockObject(H LL W BRUSH) GetStockObject(NULL BRUSH) OlbOOl? GetStockObject(BLACK PEN) b GetStockObject(NULL PEN) OlbOOOlB GetStockObject(WHITE PEN) a GetStockObject(ANSI FIXED FONT) a GetStockObject(ANSI VAR F NT) a GetStockObject(DEFAULT GUI FONT) a GetStockOb ect (SYSTEH FONT) a S GetStockObject(SYSTEM FIXED FONT) Oh, ect în GetOMJfcttType j ИІіИіиИ^^ИІIIIIIIІИ^ИІУМИ^^^ИІ^^II^^И Orez Descifrarea manipulatoarelor GDI În partea de sus a paginii sunt două casete combinate pentru a selecta modul în care va fi creat obiectul (de la diverse apeluri la GetStockObject la CreateEnhMetafile) și numărul de instanțe (de la la ) După ce ați ales metoda de creare și numărul de instanțe, faceți clic pe butonul Creare - programul va crea numărul specificat de obiecte Manipulatoarele rezultate din crearea obiectelor sunt afișate într-o listă mare în notație hexazecimală, împreună cu numele funcției creatoare și numărul ordinal din grup (numerotarea începe de la ) Bucla de creare se termină atunci când apelul funcției de creator eșuează sau când este returnat același handle ca și apelul anterior Să rulăm câteva experimente, să observăm procesul de creare a obiectelor GDI și să analizăm tiparele în valorile manipulatorilor Înțelegerea manipulatorilor de obiecte GDI Manipulatoare standard de obiecte - constante Mânerele returnate de funcția GetStockObject sunt întotdeauna constante, indiferent de ordinea în care sunt apelate De exemplu, funcția GetStockObject(BLACK BRUSH) returnează un obiect perie neagră standard (încorporat) cu mânerul x ; GetStockObject(BLACK PEN) returnează un obiect stilou negru standard cu mânerul x și așa mai departe Chiar dacă rulați două instanțe ale acestui program, GetStockObject returnează aceleași valori în ambele procese Se poate presupune că obiectele încorporate sunt create în timpul inițializării sistemului și reutilizate de toate procesele HGDIOBJ nu este un pointer Deși fișierele antet Windows definesc mânerele GDI ca pointeri, la o inspecție mai atentă, acestea nu seamănă deloc cu pointerii Creați niște obiecte GDI și uitați-vă la manipulatoarele rezultate; veți vedea că valorile lor variază de la x la xba Dacă o valoare de tip HGDIOBJ ar fi de fapt un pointer, așa cum afirmă fișierul antet wingdi h, atunci limita inferioară ar corespunde unui pointer invalid către o zonă liberă a spațiului de adrese al utilizatorului, iar limita superioară s-ar adresa nucleului spatiu de adresare Se poate presupune că manipulatorii GDI nu sunt cu adevărat indicatori Încă un fapt atrage atenția: valorile manipulatorilor obținute din apelurile către GetStockObject(BLACK PEN) și GetStockObject(NULL PEN) diferă doar cu , ceea ce este clar mai mic decât cantitatea de memorie necesară pentru stocarea obiectelor GDI interne dacă manipulatorii erau într-adevăr indicători Prin urmare, este sigur să spunem că HGDIOBJ nu este un pointer Numărul maxim de handle GDI per nivel de proces Dacă apelați funcția CreatePen de ori, vor fi create pixuri logice noi Dar dacă încercați să creați de stilouri logice, nu toate apelurile de funcții vor avea succes În timpul testării, aproximativ de stilouri sunt create cu succes, iar restul apelurilor eșuează Rețineți că atunci când se întâmplă acest lucru, valorile din casetele combinate Creator și Copii nu se afișează corect În plus, nici măcar nu veți putea salva o captură de ecran cu tasta PrintScreen dacă fereastra principală a programului GDIHandles este în prim-plan Dar dacă activați un alt program, tasta PrintScreen funcționează bine NOTĂ - - Testele noastre au arătat că Windows NT stabilește cote de proces pentru numărul de handle GDI, astfel încât un singur proces nu poate perturba întregul sistem GDI Totuși, în prima versiune de Windows , această restricție nu este respectată, ceea ce poate fi considerat un defect Capitolul Structuri interne de date GDI/DirectDraw Și încă o circumstanță interesantă: când CreatePen încetează să creeze noi obiecte GDI în acest proces, alte procese din sistem funcționează normal Se pare că există o limită per proces a numărului de puncte GDI active de aproximativ Numărul maxim de manipulatoare GDI la nivel de sistem este de Acum rulați două instanțe ale programului GDIHandles pe același sistem și încercați să apelați CreatePen de de ori în fiecare proces Primul proces va crea toate obiectele solicitate, iar al doilea se va opri undeva la Când al doilea proces încetează să creeze obiecte, sistemul devine confuz Chiar dacă treceți la alt proces, toate ieșirile din ecran sunt întrerupte Deși documentația Microsoft dă impresia că obiectele GDI folosesc doar resurse locale de proces, experimentul arată clar că obiectele GDI sunt alocate din grupul de resurse la nivel de sistem Astfel, utilizarea intensă a resurselor GDI de către un proces afectează activitatea altor procese + s Având în vedere mânerele de obiect GDI utilizate de fereastra GDIHandles și alte procese, putem presupune în mod rezonabil că numărul maxim de mânere GDI dintr-un sistem este Partea HGDIOBJ conține un index Când creați mai multe obiecte GDI cu programul GDIHandles, acordați o atenție deosebită cuvintelor de ordin scăzut ale cuvintelor duble afișate; veți vedea că valorile lor variază de la x la x FFF Cuvintele manipulatoare minore sunt întotdeauna unice în limitele procesului; în plus, unicitatea lor este păstrată între procese, cu excepția obiectelor standard Valorile cuvintelor inferioare ale manipulatorilor uneori cresc, alteori scad, iar tiparul uneori persistă chiar și între procese De exemplu, când CreatePen este apelat într-un proces, cuvântul scăzut al manipulatorului poate fi x C , iar data viitoare când CreatePen este apelat într-un alt proces, cuvântul scăzut al manipulatorului este x C Aceste fapte au o explicație simplă: cuvântul de ordin scăzut HGDIOBJ este un index într-un tabel la nivel de sistem care conține informații despre ( x ) obiecte GDI Partea HGDIOBJ conține tipul obiectului GDI Pe Windows NT/ , mânerul obiectului GDI este întotdeauna returnat ca un număr de de biți Programul GDIHandles afișează acest număr ca cifre hexazecimale După cum se arată mai sus, cele cifre hexazecimale inferioare ale mânerului GDI conțin indexul obiectului, astfel încât să ne ocupăm de cele cifre hexazecimale superioare Înțelegerea manipulatorilor de obiecte GDI Dacă creați obiecte după tip (de exemplu, creați mai multe pensule, apoi mai multe pixuri, mai multe fonturi, contexte de dispozitiv etc ), este ușor de observat că manipulatorii GDI ai obiectelor de același tip au ceva în comun - și anume, a treia și a patra cifră hexazecimală se potrivesc aproape întotdeauna cu manipulatorii lor Pentru pensule, a treia și a patra cifră ale manipulatorului sunt întotdeauna x și x ; pentru pene - x și xb ; fonturile au x a și x a; paletele au x și x ; rasterele au x , iar contextele dispozitivului au x Manipulatoarele cu bitul cel mai semnificativ din acest grup de cifre egal cu aparțin obiectelor standard Astfel, avem suficiente motive pentru a afirma că a treia și a patra cifră hexazecimală ale manipulatorului conțin atributul tipului de obiect și atributul obiectului GDI standard Semnificația celor două cifre hexazecimale rămase ale manipulatorului GDI pe de biți este încă neclar Să rezumam ceea ce știm despre manipulatoarele Windows NT/ Mânerul obiectului GDI începe cu biți înalți, a căror semnificație nu este încă cunoscută; urmat de: bit al unui flag de obiect standard, biți cu informații despre tipul obiectului și un index de biți, cei biți superiori fiind întotdeauna Cunoaștem valorile tipului de obiect de biți pentru contextul dispozitivului, regiunea, rasterul, paleta, fontul, pensula, metafișierul îmbunătățit, stiloul și stiloul îmbunătățit Structura manipulatorului GDI este prezentată în fig Orez Structura mânerului GDI în Windows NT/ Mai jos sunt câteva definiții și funcții de tip C++ care facilitează codificarea și decodarea manipulatorilor GDI typedef enumerare { gdi objtypeb dc " x gdi objtypeb reg on = x , gdi objtypeb b tmap = x gdi objtypeb pâlette = x gdi objtypeb font = OxOa gd objtypeb brush = x gdi objtypeb enhmetâfile = x Capitolul Structuri interne de date GDI/DirectDraw gdi objtypeb pen = x , gdi objtypeb extpen= x }: ini ine HGDIOBJ makeHGDIOBJ(nesemnat top, bool stock, tip de obiect nesemnat index nesemnat) { întoarcere ((sus & OxFF) « ) | ((stoc și ) « ) | ((tipul obiectului și x F) " ) | (index și x FFF): } inline bool IsStockObj(HGDIOBJ hGDIOBj) { returnează ((nesemnat) hGDIObj) x ; } inline nesemnat GetObjType(HGDIOBJ hGDIOBj) ( return ((nesemnat) hGDIObj) » ) & x F; ) inline nesemnat GetObjIndex(HGDIOBJ hGDIOBj) { return ((nesemnat) hGDIObj & x FFF): } Folosind aceste funcții, puteți afla dacă mânerul aparține unui obiect GDI standard, precum și să obțineți tipul și indexul obiectului din tabel Găsirea tabelului de obiecte GDI Prin experimentarea în secțiunea „Înțelegerea mânerelor obiectelor GDI”, am descoperit că cuvântul scăzut al mânerului obiectului GDI (HGDIOBJ) conține un index între și x FFF Există o presupunere că undeva există un tabel de obiecte GDI gestionat de sistem (cel mai probabil GDI), iar indecșii se referă la elementele acestui tabel Astfel de tabele au existat în Win și Win , așa că ar fi logic să le vedem și în Windows NT și Windows În această secțiune, vom căuta acest tabel nedocumentat În acest moment, programatorii Windows întreabă de obicei dacă este posibil să obțineți un pointer către acest tabel folosind o funcție API Win sau, mai bine, o funcție MFC generată automat de vrăjitorul MSVC Ambele întrebări vor primi un răspuns negativ Nici un singur document oficial nu confirmă chiar existența acestui tabel, ca să nu mai vorbim de funcțiile API documentate pentru lucrul cu acesta Să ieșim din imaginea unui programator care cunoaște doar funcțiile API și bibliotecă pentru o vreme și să ne imaginăm în locul lui Sherlock Holmes Găsirea tabelului de obiecte GDI În primul rând, să presupunem că există într-adevăr un tabel de obiecte GDI în sistem și vom găsi dovezi - adică să găsim acest tabel în memorie Dacă tabelul există, sunt șanse să poată fi citit din spațiul de adrese al utilizatorului Faptul este că gdi dll se află în spațiul de adrese al utilizatorului, lângă fișierele DLL și EXE Dacă acest tabel ar putea fi citit doar din spațiul de adrese kernel, atunci pentru sarcini simple, cum ar fi apelarea GetObjectTypeO GDI , ar trebui să apelați la motorul grafic win k sys în modul kernel pentru ajutor, ceea ce ar încetini foarte mult GDI Așadar, a doua presupunere a noastră este că tabelul de obiecte GDI este cel puțin citibil din programele în modul utilizator, adică în primii GB din spațiul de adrese Win Dacă există un tabel de obiecte GDI, atunci când este creat un nou obiect GDI, sunt introduse date noi în el, ceea ce îi modifică conținutul Vă rugăm să rețineți că în acest caz vorbim despre crearea unui nou obiect GDI, deoarece, așa cum se arată mai sus, funcția GetStockObjectO returnează întotdeauna același rezultat Este posibil ca acesta să returneze un manipulator creat anterior fără a crea un obiect nou, iar conținutul tabelului să nu fie modificat Dacă crearea unui nou obiect are ca rezultat modificarea tabelului de obiecte, atunci pentru a găsi tabelul, puteți compara conținutul memoriei înainte și după crearea noului obiect GDI Pe baza ipotezelor noastre, comparația poate fi limitată la spațiul de adresă al utilizatorului fără a vă face griji cu privire la spațiul de adresă în modul kernel Una dintre zonele de memorie modificate trebuie să fie în interiorul tabelului de obiecte GDI Trecem de la ideile generale la construirea unui algoritm În esență, trebuie să stocăm conținutul spațiului de adrese al utilizatorului înainte și după crearea unui obiect GDI simplu și apoi să le comparăm octet cu octet; orice locație de memorie diferită poate aparține tabelului de obiecte GDI Cu toate acestea, astfel de idei simple nu funcționează niciodată în practică Citirea primului octet din spațiul de adrese al utilizatorului care are un offset de zero are ca rezultat o eroare de securitate; acest lucru se face pentru a intercepta încercările de a dereferenția pointerii NULL Există și alte zone care nu pot fi citite în spațiul de utilizator de GB În plus, scrierea, citirea și compararea tuturor zonelor de memorie disponibile pentru aceasta va necesita o cantitate mare de spațiu pe disc și va fi foarte lentă Pentru a restricționa scanarea spațiului de adrese utilizator la zone care pot fi citite, folosim funcția Win API VirtualQiiery, care împarte spațiul de adrese virtuale în blocuri cu aceleași steaguri de securitate (de exemplu, acces numai în citire, scriere și execuție) Construirea de sume de control pentru zonele de memorie care pot fi citite reduce semnificativ cantitatea de memorie implicată în salvarea și compararea Mai jos este un algoritm de lucru cu o funcție care salvează conținutul blocurilor de memorie și le compară Capitolul Structuri interne de date GDI/DirectDraw vold shot(vector & Reglons) { MEMORY BASIC INFORMATION informații: pentru (LPBYTE start=NULL: VirtualQuery(start & info sizeof(info)): ) { dacă (info State == MEM COMMITED) { CRegion * pRgn = Regions Lookup(start, info RegionSize): dacă (pRgn==NULL) pRgn = Regions Add(start, info RegionSize); pRgn->CRC[ ] = pRgn->CRC[l]: pRgn->CRC[l] = GenerateCRC(start info RegionSize): pRgn->usage++: if ( (pReg->utilizare >= ) && (pReg->CRCCO]!=pReg->CRC[lJ) ) printfC'Possible Table location X x" start); } start +- info RegionSize: } } void SearchGDIObjectTable(void) { vector UserRAM; shot(UserRAM); CreateSolidBrush(RGB(Oxll x x )): shot(UserRAM): } Această interfață stângace este inacceptabilă în zilele noastre, așa că o nouă pagină Locate GDI Handle Table este creată în fereastra programului GDIHandles Afișează o listă tabelară în care, pentru fiecare bloc, sunt afișate suma de control, adresa de pornire, dimensiunea, starea, tipul și chiar numele modulului și al segmentului (dacă pot fi determinate) Pentru module precum gdi dll, numele modulului este determinat de funcția GetModuleFileName Pentru secțiunile unui modul PE (de exemplu, o secțiune text, care de obicei conține cod executabil), programul determină numele secțiunii uitându-se la structura internă a fișierului PE În plus, programul încearcă să identifice blocuri cu grămezi de proces și stive de fire de program Pagina are un buton Query Virtual Memory care vă permite să obțineți o „instantanee” a memoriei virtuale în orice moment Rulați programul și faceți clic pe butonul Interogare memorie virtuală; funcția VirtualQuery împarte spațiul de adrese virtuale de GB în peste de blocuri Majoritatea blocurilor sunt marcate cu F (memorie liberă, liberă) și R (memorie rezervată, rezervată) Suntem interesați de blocurile cu flag C (memorie comisă, actualizată) Găsirea tabelului de obiecte GDI Cele mai multe blocuri actualizate conțin segmente de fișiere EXE ale programelor și DLL-urilor de sistem - cum ar fi kernel dll, gdi dll și chiar msidle dll (este greu de spus de ce msidle dll este mapat la acest spațiu de adrese, dar faptul rămâne) Mai multe blocuri conțin grămezi; un bloc conține stiva Pentru fiecare bloc actualizat, în stânga este afișată o sumă de control Accesați pagina Decode GDI Handle, creați o perie uniformă, reveniți la pagina Locate GDI Handle Table și creați un al doilea instantaneu de memorie De data aceasta, pentru aproape toate blocurile actualizate, avem două sume de control (înainte și după crearea obiectului) Unele blocuri pot avea o singură sumă de verificare, deoarece adresa lor de pornire sau dimensiunea s-au schimbat Pe fig Figura arată cum arată ecranul după ce a fost făcut al doilea instantaneu al memoriei virtuale L" GD! Mânere - (processOxBBC) La esOe af cl OOZOOOOOO b c RMH er er oozzooo F f f CI euc Mânere **** OQUO MLML O b OOOZaOOO CI euc text b bl b CI euc rdata mmime QQ / / dd f CI eve date = d d CI ewc ££ dla dla CI ewc rsrc a F aiba f a CM ro OOOOdOOO F & a CMer a RHer b b a C p ru LPL L I OPP lppl ^ ppp K executabil Dacă S * Și ❖ / g "ang L' 'g g 'y* -ț 'Y', - ~ți: - Virtual Jmyuhgg / K-= eu Shay' Orez Căutare în tabelul obiectelor GDI (blocuri modificate marcate) Blocurile cu sume de control identice sunt precedate de un semn verde de egalitate, iar blocurile cu sume de control diferite sunt precedate de un semn de avertizare roșu Blocurile cu aceeași sumă de control după două instantanee sunt de asemenea considerate modificate Capitolul Structuri interne de date GDI/DirectDraw NOTĂ - Fiecare programator Windows calificat ar trebui să aibă o bună înțelegere a mecanismului memoriei virtuale Acest lucru vă va ajuta să înțelegeți mai bine cum funcționează API-ul Win și cum funcționează programul dvs De exemplu, memoria virtuală începe cu un bloc liber de de kiloocteți la adresa zero Dacă ați încercat vreodată să dereferiți un pointer ai cărui biți superiori sunt zero, ați accesat această „zonă fantomă” Deoarece acest bloc de memorie virtuală este declarat liber, orice încercare de citire/scriere duce la erori de protecție Fiecare fir din programul dvs creează o stivă separată, reprezentată în memoria virtuală de trei blocuri: un bloc mare rezervat pentru creșterea stivei, un bloc „watchdog” de o pagină pentru detectarea creșterii stivei și un bloc actualizat pentru porțiunea stivei care este de fapt folosit Toate DLl/EXE din programul dvs își pot crea propriile heap-uri, atâta timp cât nu folosesc versiunea DLL a bibliotecii de rulare C/C++ (de aceea heap-urile sunt atât de comune în memoria virtuală) Modulele utilizator sunt de obicei încărcate în partea de jos a memoriei virtuale, iar DLL-urile de sistem în partea de sus Cel mai mare bloc liber dintre ele determină cantitatea maximă de date care poate fi procesată de un program Win în același timp De obicei, acest bloc liber de memorie virtuală este de aproximativ , gigaocteți În testul nostru, între două „instantanee” de memorie, aproximativ zece blocuri aveau sumele de control modificate sau adresa/dimensiunea lor de pornire schimbată În acest caz, au avut loc mai multe evenimente - ieșirea rezultatului primului „instantaneu”, trecerea la o altă pagină, crearea unei pensule uniforme și revenirea la pagina anterioară Deoarece aceasta a creat cel puțin un nou obiect GDI, tabelul de obiecte GDI trebuie să fie într-unul dintre aceste blocuri Cu toate acestea, zece blocuri sunt încă prea multe pentru a parcurge unul câte unul Cu toate acestea, majoritatea candidaților pot fi respinși definitiv, deoarece dimensiunea blocului trebuie să fie mai mare decât o anumită valoare de prag Știm din secțiunea anterioară că numărul maxim de mânere de obiecte GDI este de pentru un singur proces sau pentru întregul sistem Presupunând că fiecare intrare din tabelul obiect GDI este codificată cu un minim de patru octeți, dimensiunea tabelului trebuie să fie mai mare de KB ( x în notație hexazecimală) Patru octeți reprezintă cantitatea minimă de memorie pentru a stoca un pointer către o structură de date mai complexă Având în vedere restricțiile de dimensiune, rămân doar două blocuri (ambele vizibile în Figura ) Ambele blocuri sunt actualizate, protejate la scriere și nu au nume semnificative Ambele sunt destul de mari, KB ( x ) și KB ( x ) Un bloc are un atribut PAGE READONLY, iar celălalt are un atribut PAGE EXECUTE READ Pentru a înțelege în ce bloc poate fi amplasat tabelul pe care îl căutați, cel mai simplu mod este să vizualizați conținutul acestora Făcând dublu clic pe prima coloană a tabelului, pe ecran apare o casetă de dialog, care afișează un dump hexazecimal al blocului selectat Acum dublu clic pe prima coloană a blocului începând cu x Convertiți dump-ul în format de cuvânt dublu (butonul radio Dword este setat pentru aceasta) Când vizualizați conținutul blocului, devine în curând clar că aveți un tabel cu elemente de octeți Pentru a vă asigura că tabelul de la x este într-adevăr tabelul de obiecte GDI dorit, salvați conținutul blocului într-un fișier text (butonul Dump), creați mai multe obiecte GDI, amintiți-vă manipulatorii acestora, Găsirea tabelului de obiecte GDI stocați un nou dump din același bloc și comparați cele două fișiere cu un utilitar (cum ar fi WinDiff) Să presupunem că ați creat de pensule uniforme și ați primit mânere cu valori de la x la x b; indicii acestor manipulatoare se află în intervalul de la x la x b Vizualizați dump-ul la adrese de la x la x b ; veți vedea că după ce obiectele au fost create, conținutul acestor adrese s-a schimbat Pe fig Figura prezintă o descărcare a unui bloc de memorie care începe la adresa x | ІІУ L: [ x G Bjt' G Word- & OWctd : e! s± OOOQOOOG D GGGG • ? e* ^ X : © L HM- : © L * *: * *■****,,,» : © : © ? © ^ GUGG &G ,C? , ? © © OHOOlbO , w» «| ||[|n| Riga Căutare fiK Orez Evacuarea memoriei posibilelor tabele de obiecte GDI În acest program, tabelul de obiecte GDI a fost găsit la adresa x , dar nu există niciun motiv să credem că această adresă este fixă Dacă te uiți cu atenție la structura memoriei virtuale, vei vedea că blocul x se află în memorie după programul principal Handles exe Prin urmare, pentru un program mai mic, tabelul de obiecte ar putea începe la x , iar pentru un program mare, la x Avem nevoie de o modalitate mai ușoară și mai fiabilă de a căuta un tabel în memorie Deoarece adresa tabelului nu este fixată în memorie, iar GDI trebuie să o acceseze adesea, putem concluziona că o referință la tabel trebuie să fie prezentă în segmentul de date GDI Deschideți dialogul Memory Dump pentru secțiunea de date GDI ( data), comutați la modul Dword (buton radio Dword), introduceți adresa și faceți clic pe butonul Căutare Următorul raport apare pe ecran: Căutați x în regiune începe de la f dimensiune de octeți f f bc Cele două referințe găsite înseamnă că gdi dll stochează două variabile interne pentru accesarea tabelului de obiecte GDI Să continuăm căutarea în secțiunea cod GDI ( text) cu adresele acestor două variabile, x f și x f bc Există patru referințe la a doua variabilă și câteva sute la prima Compararea adresei cu ieșirea Quick- Capitolul Structuri interne de date GDI/DirectDraw View sau Dumpbin pentru gdi dll arată clar că referințele apar în multe funcții, inclusiv SelectObject și GetObjectType Cu toate acestea, printre funcțiile care folosesc indicatori de tabel obiect GDI, o funcție nedocumentată de interes deosebit este GdiQueryTable Un nume extrem de curios sugerează că există un tabel undeva, iar folosind această funcție poți obține informații despre el Să vedem ce face această funcție misterioasă // querytab cpp #def ne STRICT # nclude typedef nesemnat (CALLBACK * ProcO) (void); void TestGdlQueryTable(vold) { ProcO p = (ProcO) GetProcAddress(GetModuleHandle("GDI DLL") "GdiQueryTable"); daca(p) { TCHAR temp[ ]; wspr ntf(temp, ' X" p()); MyMessageBox(NULL, temp, „Gd QueryTable() returnează” MB OK); } întoarce ; } Funcția GdiQueryTable returnează aceeași adresă x care a fost obținută experimental După multe probleme cu căutările de memorie virtuală, ne-am atins obiectivul - într-adevăr, Windows NT/ are un tabel de obiecte GDI la nivel de sistem și chiar are o funcție GdiQueryTable nedocumentată care returnează un pointer către acest tabel În programele în modul utilizator, acest tabel este doar pentru citire Dacă aveți fișierele simbol pentru gdi dll instalate pe computer, rulați programul Handles exe în modul de depanare, comutați în modul cod de asamblare și alegeți Editare ► Go Apoi, pe ecran apare o casetă de dialog Introduceți adresa x f sau x f bc în ea Depanatorul Visual C++ arată pGdiSharedHandleTable pentru prima adresă și pGdiSharedMemory pentru a doua Deci, prima adresă corespunde unui pointer către tabelul de obiecte GDI partajat, iar a doua unui pointer către memoria GDI partajată, ambele blocuri de memorie începând de la aceeași adresă Dacă introduceți numele GdiQueryTable@O în loc de adresă (sufixul înseamnă că funcția este apelată fără parametri), depanatorul va afișa codul de asamblare al funcției nedocumentate GdiQueryTable Funcția este elementară - pur și simplu returnează conținutul indicatorului pGdiSharedHandleTable Decodificarea tabelului de obiecte GDI În secțiunea „Înțelegerea mânerelor obiectelor GDI”, s-a afirmat că numărul maxim de mânere dintr-un tabel este Decodificarea tabelului de obiecte GDI și că este accesibil din spațiul de adrese în modul utilizator Pe fig prezintă conținutul inițial al tabelului de obiecte GDI La o examinare mai atentă a gropii din fig Figura prezintă un model clar de cicluri la fiecare octeți: mai întâi o valoare mare de de biți, apoi o valoare nulă de de biți, o altă valoare de de biți diferită de zero și alți de biți nul Dimensiunea tabelului de obiecte GDI presupus este de KB, care atunci când este împărțit la este , Deci, este sigur să spunem că dimensiunea intrării în tabelul obiect GDI este de octeți Sarcina principală a acestei secțiuni va fi de a descifra structura acestei înregistrări de octeți Folosind metodele experimentale descrise în cele două secțiuni anterioare, se poate ajunge la următoarea structură: typedef struct { void * pKernel: unsigned short nProcess; nesemnat scurt nCount; unsigned short nllpper: unsigned short nType; void* plser; }GdITableCell; Primii octeți ai intrării din tabelul GDI conțin un pointer a cărui valoare este de obicei mai mare de xE Prin urmare, se referă la primii gigaocteți ai spațiului de adrese Windows NT/ , accesibil doar codului în modul kernel Aceasta înseamnă că pentru fiecare obiect GDI din spațiul de adrese în modul kernel, există o structură de date care este referită de tabelul de obiecte GDI NOTĂ - - În Windows NT/ , zona de memorie de la x la xECFFFFFF ( MB) este un pool de nucleu paginat care stochează structuri de date ale componentelor nucleului alocate dinamic Diferă de pool-ul nepaginat prin faptul că primul poate fi paginat pe disc atunci când nu există suficientă memorie de sistem, în timp ce se știe că cel din urmă rămâne întotdeauna în memoria fizică După cum va fi arătat mai jos, structurile de date GDI în modul kernel (inclusiv hărți de biți dependente de dispozitiv, DDB) sunt de obicei stocate în pool-ul paginat Următorii doi octeți (câmpul nProcess) conțin ID-ul procesului care a creat obiectul ID-ul procesului curent este returnat de funcția GetCurrentProcessId Pentru unele obiecte (de exemplu, obiecte GDI standard), acest câmp poate fi Cei doi octeți care urmează nProcess sunt de obicei zero Cu toate acestea, în anumite condiții, valoarea poate fi diferită de zero Ele par să stocheze un număr de ori când manipulatorul obiectului a fost folosit; din acest motiv, acest câmp este numit nCount în definiția structurii Câmpul nCount este urmat de câmpul nllpper, care este o copie exactă a primilor doi octeți ai mânerului obiectului GDI Știm din secțiunile anterioare că nllpper constă dintr-un octet mare necunoscut și un octet mic cu informații despre tipul obiectului Capitolul Structuri interne de date GDI/DirectDraw Câmpul nUpper este urmat de un câmp nType de octeți care conține informații interne despre tipul obiectului Ultimii octeți ai GdiTableCell (câmpul pUser) conțin un alt pointer De obicei, pUser este NULL Dacă acest câmp nu este NULL, stochează un pointer către cei gigaocteți de jos de spațiu de adrese disponibil pentru codul modului utilizator Pentru unele tipuri de obiecte, GDI creează o structură de date care este locală procesului curent Indicatorii pentru modul utilizator sunt accesibili din spațiul de adrese în modul kernel, dar numai dacă se referă la procesul curent Deci, știm cum să obținem adresa tabelului obiect GDI și ce structură are fiecare element al tabelului Toate aceste informații vor fi combinate într-o clasă C++ care facilitează lucrul cu un tabel de obiecte GDI în programele Windows Clasa KGDITabl e este prezentată în Lista Lista Clasa KGDITable pentru lucrul cu tabelul de obiecte GDI // GDITable h #pragma o dată clasa KGDITable { GDITableCel * pGDITable: public: KGDITable!); Operator GDITableCell[](HGDIOBJ hHandle) const { returnează pGDITableE (nesemnat) Handle & OxFFFF ]; } GDITableCel operator[](nlndex uns gned) const { returnează pGDITableE nlndex & OxFFFF ]; } }; // GDItable cpp #def ne STRICT # nclude # nclude # ncludeți „Gditable h” KGDITable::KGDITable() typedef nesemnat (CALLBACK * ProcO) (vold); ProcO pGdiQueryTable = (ProcO) GetProcAddress( GetModuleHandle("GDI dl ", "GdiQueryTable"); assert(pGdiQueryTable); dacă (pGdiQueryTable) pGDITable = (GDITableCel *) pGdiQueryTable(): el se Decodificarea tabelului de obiecte GDI { pGDITable = NULL; } Lucrul cu clasa KGDITable este foarte ușor Următoarele arată cum să obțineți adresa structurii de date în modul kernel pentru obiectul stilou negru standard const void * BlackPenpKernel(void) { KGDITable gditable; returnează gditable[GetStockObject(BLACK PEN)] pKernel; } Pe fig Figura arată noua pagină de proprietăți, Decode GDI Object Table, a programului nostru GDIHandles Această pagină afișează conținutul tabelului de obiecte GDI într-un mod structurat /? OSI Decodare GDI Mâner | Locale GDI Handle Table Decode GDI Handte Table | •țî-P' Ozhu yo I IQuery GDI Table b K î" nu, % e ale c elec c a S a elec c c eeOa a e d elec e c SeOl a d d e c B e eZ c c el f eZ e c a a f e c a a e e c b e S c f a a e SaS e c c leOa a e a e a aa c B Index: , Mâner: , Tip: OBJJBITMAP ' '' | Sapsy Orez Conținutul tabelului de obiecte GDI Folosind caseta de selectare situată în colțul din stânga sus al paginii, utilizatorul alege între afișarea tuturor obiectelor din tabel sau doar a acelei obiecte care au fost create de procesul curent Încercați să evidențiați oricare Capitolul Structuri interne de date GDI/DirectDraw obiect GDI din listă; informații suplimentare despre indexul său, valoarea HGIOBJ și tipul de obiect vor apărea în partea de jos a paginii Cu un astfel de instrument minunat de afișare a conținutului unui tabel de obiecte GDI, putem face mai multe experimente cu obiectele GDI și putem explora mai profund modul în care aceste obiecte sunt gestionate Pointerul pKernel se referă la pool-ul paginat Pentru orice obiect GDI valid, pointerul pKernel este întotdeauna non-NULL și are o valoare unică Se pare că există o structură de date pentru fiecare obiect GDI care este accesat doar din codul în modul kernel (și nici măcar din gdi dll!) După cum se poate vedea din valorile pKernel, obiectele diferitelor procese nu au o împărțire clară în diferite zone de memorie Adresele obiectelor indicate de pKernel încep întotdeauna cu xEIOOOOOOO După cum s-a raportat în cartea În interiorul Windows NT, zona de memorie care începe cu OxEIOOOOOOO este heap-ul de sistem paginat, denumit în mod obișnuit pool paginat Visual C++ nu dereferențează acești indicatori, așa că nu vom putea afla încă ce se află în spatele lor În esență, Visual Studio este un program obișnuit în modul utilizator, care nu este acceptat de drivere speciale de kernel Vom reveni la pointerul pKernel din WinDbg și la extensia GDI Debugger și o vom examina folosind driverul pentru modul kernel pe care îl vom crea în secțiunea Acces la spațiul de adrese în modul Kernel Câmpul nCount este uneori folosit ca contor de selecție a obiectelor Pe Windows , câmpul nCount este întotdeauna zero, ceea ce înseamnă că nu este utilizat Cu toate acestea, în Windows NT acest câmp este obligatoriu pentru unele obiecte GDI Pentru a înțelege mai bine sensul nCount, experimentați cu selectarea și restaurarea obiectelor într-unul sau mai multe contexte de dispozitiv și urmăriți schimbarea nCount În esență, trebuie să creați un obiect, să-l selectați în două contexte de dispozitiv, apoi să restaurați obiectele vechi și, în final, să ștergeți obiectul creat După cum reiese din acest mic experiment, atunci când un obiect este creat, câmpul său nCount este zero și pentru multe tipuri de obiecte această valoare rămâne neschimbată Pentru rasterele dependente de dispozitiv (DDB), câmpul nCount se modifică de la la atunci când un obiect este selectat într-un DC Dacă încercați să reselegeți un raster într-un DC diferit, încercarea va eșua Când un raster este exclus din primul DC, câmpul nCount revine la starea zero Cu siguranță, în legătură cu DDB, câmpul nCount impune cerința că un raster nu poate fi selectat în mai multe contexte în același timp Pentru fonturi, un alt tip de obiect GDI care folosește câmpul nCount, acest câmp stochează un număr de selecție simplă care nu impune nicio restricție Decodificarea tabelului de obiecte GDI leziuni Selectarea fontului logic în al doilea context de dispozitiv are succes, iar valoarea câmpului nCount este incrementată Mulți programatori pun o întrebare evidentă - există vreun mecanism în GDI pentru a proteja împotriva ștergerii obiectelor selectate în contextul dispozitivului? Răspunsul este da, există cel puțin pentru palete După cum se vede din tabel , primul apel către DeleteObject după selectarea paletei din două DC-uri eșuează, dar al doilea apel la DeleteObject după excluderea paletei din ambele DC-uri funcționează bine Cu toate acestea, câmpul nCount nu este utilizat în această protecție Alte obiecte GDI (de exemplu, fonturi, hărți biți, pensule și pixuri) pot fi șterse de programator în orice moment, invalidând astfel mânerul obiectului selectat Este greu de spus de ce Windows nu acceptă reguli uniforme de utilizare nCount care împiedică ștergerea tuturor obiectelor selectate Tabelul Folosind câmpul nCount Funcția API Paleta de fonturi Raster (DDB) Creare () Succes, nCount= Succes, nCount= Succes, nCount= SelectObject(hDCl) Success, nCount=l Success, nCount=l Success, nCounte SelectObject(hDC ) Fail, nCountsl Success, nCount= Success, nCounte DeleteObjectO a eșuat (De)SelectObject(hDC ) Fail, nCount=l succes, nCount=l success, nCounts (De)SelectObject(hDCl) Success, nCount= Success, nCount= Success, nCounte DeleteObjectO Succes Succes Succes Câmpul nProcess asociază mânerul GDI cu un anumit proces Dacă un program încearcă să folosească mânerul unui obiect GDI care aparține altui proces, apelul API Win eșuează de obicei În spatele acestei „magie” se află câmpul nProcess al structurii GdiTableCel Pentru obiectele standard (de exemplu, GetStockObject(BLACK PEN)), câmpul nProcess este zero Pentru alte obiecte GDI create de procesele utilizator, câmpul nProcess conține ID-ul procesului care a creat obiectul Pentru a obține ID-ul procesului curent, apelați funcția GetCurrent-ProcessIdO GDI verifică dacă ID-ul procesului curent se potrivește cu conținutul câmpului nProcess al obiectului GDI; aceasta impune cerința ca mânerele obiectelor să nu fie utilizate de alte procese Pagina Decode GDI Object Table vă permite să alegeți între afișarea tuturor obiectelor GDI sau numai a acelor obiecte create de procesul curent Dacă faceți clic pe un rând de tabel, se afișează partea de jos a paginii Capitolul Structuri interne de date GDI/DirectDraw informații detaliate despre obiectul selectat, inclusiv informațiile returnate la apelarea GetObject Dar dacă comutați pentru a afișa toate obiectele GDI și faceți clic pe un obiect creat de un alt proces, apelul GetObject eșuează și programul afișează o eroare „Obiect nevalid” Conform documentației Microsoft, atunci când un proces se încheie, toate obiectele GDL pe care le-a creat sunt eliberate Te-ai întrebat vreodată cum se face acest lucru? GDI pur și simplu iterează prin toate intrările din tabelul de obiecte GDI și elimină toate obiectele cu ID-ul procesului curent nSuper: verificare suplimentară Câmpul nUpper din tabelul de obiecte GDI conține o copie exactă a celor doi octeți înalți ai mânerului de octeți — această redundanță relativ mică oferă validare suplimentară pentru mânerele de obiect GDI Să presupunem că ați creat un font; funcția CreateFont returnează x d a f Noul obiect corespunde elementului de tabel cu indexul x f, al cărui câmp nUpper este egal cu x d a Acum o altă parte a programului elimină fontul fără să știe că este în uz, ceea ce duce la eliberarea intrării x f; apoi programul creează un alt font Să presupunem că GDI decide cumva să folosească elementul x f pentru noul obiect GDI și îi atribuie mânerul x e a f Dacă prima parte a programului încearcă să folosească manipulatorul x d a f, apelurile funcției Win GDI vor eșua - GDI detectează că x d a nu se potrivește cu noua valoare nUpper a x f, care este acum x peOa Încercați să schimbați octetul înalt al mânerului GDI păstrând în același timp ceilalți trei octeți, care stochează informații despre tipul obiectului; veți vedea că apelurile la GetObject și GetObjectType eșuează Stocarea cuvântului înalt al manipulatorului într-un tabel are alte utilizări Dacă cunoașteți doar indexul manipulatorului din tabelul GDI, puteți recupera întregul manipulator citind nUpper din tabel și concatenând cele două valori De exemplu, această caracteristică este utilizată la implementarea suportului GDI pe biți în Windows NT Amintiți-vă că interfața GDI pe biți utilizează un mâner HGDIOBJ pe biți, care este efectiv un index Pentru ca suportul GDI pe biți să funcționeze pe Windows NT, apelul trebuie redirecționat către o interfață GDI pe de biți care funcționează cu manipulatoare complete pe de biți La analizarea structurii manipulatoarelor GDI în secțiunea „Căutarea unui tabel de obiecte GDI”, doar cei biți superiori au rămas necodați Experimente suplimentare arată că stochează un contor de reutilizare, o altă modalitate ușoară de a testa manipulatorii Fiecare intrare din tabelul obiect GDI are o valoare inițială a contorului de Când un nou obiect GDI este introdus în intrarea tabelului, contorul său de reutilizare este incrementat (când valoarea ajunge la , contorul este resetat la ) Astfel, atunci când un element este utilizat pentru prima dată, numărul său de reutilizare este x ; acest lucru se aplică tuturor obiectelor GDI standard care sunt create o singură dată și nu sunt niciodată șterse Dacă Decodificarea tabelului de obiecte GDI ștergeți obiectul GDI și creați un obiect nou în același element de tabel, chiar dacă tipurile de obiecte se potrivesc, manipulatorii vor fi diferiți deoarece contorul de reutilizare a crescut Toate apelurile de funcții care conțin manipulatorul original vor eșua Utilizarea contorului este demonstrată în secțiunea „Structuri de date în modul utilizator” (mai jos) pType: tip de obiect intern În procesul de analiză a structurii manipulatoarelor GDI (vezi secțiunea „Descifrarea manipulatoarelor de obiecte GDI”), am aflat că fiecare manipulator conține informații de biți despre tipul obiectului Aceste informații, extinse la doi octeți, sunt disponibile și în tabelul de obiecte GDI Octetul mic al pType conține de obicei aceiași biți de tip ca HGDIOBJ, iar octetul mare este de obicei zero În câmpul pType, mânerul de metafișier îmbunătățit este interpretat ca mâner de context de dispozitiv, iar mânerul de creion îmbunătățit este interpretat ca mâner de perie Pentru unele obiecte, octetul mare al pType definește subtipul obiectului, de exemplu, subtipul „context de memorie” al tipului „context dispozitiv” Iată ce știm despre acest cuvânt de tip obiect interior: typedef enumerare gdi int objtypew dc gdi nt objtypewjnemdc gdi int objtypew reg on gdi i nt objtypew b tmap gdi nt objtypew pa ette gdi nt objtypew font gdi nt objtypew gdi nt objtypew enhmetafile = x gd nt objtypew pen gdi i nt objtypew extpen = x = x = x = x = x = x a = x // Nu toate contextele compatibile // Cât despre DC = x = x // Cât despre o pensulă pUser: pointer către structura de date în modul utilizator Poate că ați observat aranjarea simetrică a câmpurilor în structura GdiTableCell: începe cu un pointer, urmat de patru cuvinte de biți și apoi un alt pointer pUser În mod normal, pointerul pUser este NULL, cu excepția anumitor tipuri de obiecte GDI Dacă pointerul este non-NULL, acesta ia valori precum x c sau x După cum puteți vedea cu ușurință, aceste valori corespund adreselor reale ale blocurilor de memorie disponibile pentru citire și scriere Structurile de date ale obiectelor GDI sunt discutate mai detaliat în secțiunea următoare Capitolul Structuri interne de date GDI/DirectDraw Structuri de date în modul utilizator După cum se arată în secțiunea anterioară, fiecare obiect GDI are o intrare în tabelul global de obiecte GDI care stochează un pointer numit pUser Pentru majoritatea obiectelor GDI, pointerul pUser este NLILL (adică nu este utilizat) Cu toate acestea, pentru obiectele pensulă, regiuni, fonturi și contexte de dispozitiv, câmpurile pUser din tabelul de obiecte GDI se referă la unele structuri de date destul de interesante în spațiul de adrese în modul utilizator Această secțiune este dedicată acestui subiect Structura de date în modul utilizator pentru pensule: optimizarea creării pensulelor uniforme Pentru perii uniforme, pointerul pUser indică un bloc de de octeți, în care primii octeți conțin o copie a structurii LOGBRRUSH Dacă o pensulă este uniformă, are un singur atribut, culoarea Pentru alte tipuri de pensule, pUser conține NULL typedef struct { LOGBRUSH logbrush: DWORD dwUnused[ ]; } User Data SolIdBrush: Dacă nu înțelegeți de ce pensulele uniforme au un loc special în implementarea GDI, să încercăm să punem întrebarea diferit - prin ce se deosebesc periile uniforme de alte pensule? În primul rând, aceste obiecte GDI nu trăiesc mult și sunt folosite în cantități mari Când creați umpleri în degrade, umbre sau efecte de lumină, sunt create sute și mii de pensule uniforme, utilizate o dată sau de două ori pentru a afișa un fragment dintr-o imagine și apoi șterse imediat Deoarece sunt necesare pensule uniforme în cantități mari, aplicarea nu le poate stoca decât data viitoare; în caz contrar, riscați să depășiți dimensiunea maximă a tabelului de obiecte GDI Astfel, majoritatea pensulelor omogene sunt distruse imediat după utilizare și recreate dacă este necesar Păstrând o copie a structurii LOGBRUSH în modul utilizator, GDI simplifică fluxul de lucru standard de creare-utilizare-ștergere pentru un număr mare de pensule Când prima perie omogenă este ștearsă, GDI nu distruge de fapt crearea structurii de date, ci o salvează pentru viitor Când programul are nevoie de o nouă perie uniformă, GDI ia pensula finită și își schimbă culoarea; acest lucru evită apelarea modului kernel pentru a aloca un bloc de memorie și a-l popula cu noile date pensulei Pentru a înțelege ce se întâmplă, vom face un experiment simplu Încercați să creați, să analizați și să distrugeți opt perii uniforme într-o buclă După cum se vede din tabel , GDI stochează în tabelul GDI mai multe singure Structuri de date în modul utilizator pensule native pentru utilizare ulterioară Vă rugăm să rețineți: periile , și au același indice OxZeII Câmpurile pKernel și pUser sunt aceleași, dar câmpurile IbColor din structura LOGBRUSH la care face referire pUser sunt diferite Tabelul Reutilizarea mânerelor periei uniforme Manipulator de numere IbColor pKernel pUser Întreținere x xel d x x cl f x xel d x xa ell x xel d x x be x xel da x x dl f x xel d x xa ell OxaOaOaO xel d x x fl f OxcOcOcO xel d x x Ibe OxeOeOeO xel da x Tabelul ilustrează și ceea ce sa spus mai sus despre contorul de reutilizare ( biți mai mari ai mânerului GDI) Manipulatorii , și din tabel sunt create în același element al tabelului GDI Ox eII; toate se potrivesc cu obiectul pensula ( x ), totuși contoarele lor de reutilizare diferă cu Structura de date în modul utilizator pentru regiuni: optimizarea regiunilor dreptunghiulare Obiectele regiune sunt create de funcții precum CreateRectRgn și ExtCreateRgn Prin analogie cu pensulele, câmpul pUser este folosit pentru cel mai simplu caz - regiuni dreptunghiulare Dimensiunea blocului de date pentru regiunea dreptunghiulară adresată de pointerul pUser este de de octeți Semnificația primelor două cuvinte duble din acest bloc este necunoscută, iar restul de octeți formează o structură RECT: typedef struct { DWORD dwUnknownl://= DWORD dwUnknown : //- , RECT rcBound: } UserData RectRgn; După cum v-ați putea aștepta, mânerele regiunii dreptunghiulare, precum mânerele pensulei, sunt reutilizate de GDI Încercați un experiment simplu - creați o regiune dreptunghiulară, stocați valorile pointerilor pKernel și pUser și apoi ștergeți regiunea Repetați de ori Veți vedea că GDI folosește vechiul index de trei ori fără a modifica pointerii pKernel și pUser, deși coordonatele dreptunghiului se schimbă Capitolul Structuri interne de date GDI/DirectDraw De regulă, crearea și utilizarea ulterioară a obiectelor GDI se realizează numai prin intermediul GDL Starea obiectului GDI creat este codificată În programarea orientată pe obiecte, astfel de obiecte sunt numite imuabile De exemplu, după crearea unei pensule, nu îi mai puteți schimba direct culoarea Obiectele regiune sunt o excepție de la această regulă - funcția SetRectRgn convertește o regiune existentă într-o regiune dreptunghiulară cu coordonatele date Cunoscând definiția structurii de date, indicatorul către care este stocat în câmpul pUser, puteți înțelege cu ușurință cum este implementată această funcție - GDI pur și simplu se asigură că câmpul pUser nu este gol (adică structura UserDataRectRgn a fost creată în memorie) și atribuie valorile specificate coordonatelor Astfel, regiunile ca obiecte GDI sunt mutabile Structura de date în modul utilizator pentru fonturi: tabel cu valorile lățimii Sunt definite mai multe structuri de date pentru fonturi în Windows GDI decât pentru orice alt obiect: LOGFONT, TEXTMETRIC, PANOSE, ABC, GLYPHSET și așa mai departe Cu toate acestea, nici cea mai mică urmă a acestor structuri nu se găsește în tabelul de obiecte GDI Structura de date în modul utilizator pentru un handle de font este foarte simplă: typedef struct { DWORD dwUnknown://=O void *pCharWidthData: // = , } UserData Font; Primul câmp UserData Font este întotdeauna zero Cel de-al doilea câmp este de obicei nul și este modificat numai după apeluri la funcții precum GetCharWidth Funcția GetCharWidth umple un tablou întreg cu informații despre lățimea caracterelor care aparțin intervalului specificat După un apel la GetCharWidth, pointerul pChar-WidthData indică o structură de date alocată din heap-ul de sistem care conține practic un tabel de valori cache a lățimii Iată un alt exemplu despre modul în care GDI depune un efort suplimentar în optimizarea performanței Având în vedere valoarea pCharWidthData (de exemplu, x b ), vă puteți da seama cu ușurință unde se află această adresă Pagina Locate GDI Object Table din GDIHandles afișează o listă cu toate blocurile de memorie din spațiul de adrese al utilizatorului Din această listă, puteți vedea că adresa x b aparține primului heap, adică heap-ului implicit al procesului Dacă faceți dublu clic pe rândul primului heap, pe ecran apare o fereastră de descărcare a memoriei (vezi Figura ) Faceți clic pe butonul Dump - conținutul blocului este stocat într-un fișier text împreună cu o listă a tuturor blocurilor alocate din heap Structura de date în modul utilizator pentru contextul dispozitivului: atribute Înainte de a efectua orice operațiuni de ieșire în Windows GDI, trebuie să obțineți handle-ul de context al dispozitivului Vă puteți crea propria manie Structuri de date în modul utilizator pulator sau obțineți-l din sistemul de operare Contextul dispozitivului are două duzini de atribute, ale căror valori pot fi citite și setate în programe De exemplu, atributele obișnuite ale contextului dispozitivului includ modul de afișare, culoarea textului, culoarea de fundal și obiectele de tip pensulă, creion și font selectate Desigur, GDI stochează informații despre atributele contextului dispozitivului într-o structură de date Pe Windows NT/ , un pointer către această structură este stocat în câmpul pUser din tabelul de obiecte GDI pentru handle-ul context al dispozitivului După procesul obositor de schimbare a atributelor contextului și urmărirea modificărilor datelor binare, vă puteți face o idee aproximativă despre structura la care face referire indicatorul pUser pentru contextul dispozitivului Cu toate acestea, informațiile primite vor fi incomplete și nesigure Când utilizați extensia de depanare GDI la nivel de kernel oferită de Microsoft, în combinație cu utilitarul WinDbg (depanatorul sursă la nivel de sistem de la Microsoft), apare o imagine mult mai completă și completă Utilizarea GDI Debugger Extension este descrisă în detaliu în WinDbg și GDI Debugger Extension Mai jos sunt informațiile pe care le-am putut obține despre această structură de date, care este de de octeți în Windows ( de octeți în Windows NT ) // dcattr h typedef struct { ULONG ull; ULONG u! : } FLOATOBJ: typedef struct FLOATOBJ efMll; FLOATOBJefM : FLOATOBJ efM ; FLOATOBJ efM ; FLOATOBJ efDx: FLOATOBJ ef Dy: int fxDx; ntfxDy; flAccel lung; }MATRICE; // Windows NT : x bytes // Windows : xlC bytes typedef struct { void * ULONG HBRUSH HPEN pvLDC; // ulDirty: hbrush: hpen: COLORREF ULONG crBackgroundClr: // ulBackgroundClr: Capitolul Structuri interne de date GDI/DirectDraw COLORREF crForegroundClr; ULONG ulForegroundClr; # f ( WIN WINNT >= x ) nesemnat f [ J; #endif // Int CS CP; // Int GraphlcsMode; BYTE JROP : // BYTE JBkMode; BYTE jFI Mod; BYTE JStretchBltMode; POINT ptlCurrent:// C POINTFX ptfxCurrent:// lung BkMode: // C Long IFIllMode: // lung IStretchBltMode: # f( WIN WINNT >" x ) lung flFontMapper; // lung IcmMode: hcmXform nesemnat; // HCOLORSPACE hColorSpace: nesemnat f : nesemnat IcmBrushColor: IcmPenColor nesemnat: // nesemnat f ; #endif lung flTextAl gn:// lung TextAl gn; long ITextExtra: // IRelAbs lungi; IBreakExtra lung: pauză lungă; HFONT hlfntNou; // MATRIX mxWorldToDevIce:// MATRIX mxDevIceToWorld: // D MATRIX mxWorldToPage; // IOC nesemnat fl [ J; // int IMapMode: // # f ( WIN WINNT >= x ) DWORD long #end f dwLayout; IWIndowOrgx; // c // POINT ptlWINdowOrg; // SIZE szlWINdowExt; // c Structuri de date în modul utilizator POINT ptlVIEWportOrg:// SIZE szlViewportExt:// c opd flXform:// SIZE szlVirtua DevicePixel; // SIZE szlVirtualDeviceMm; // laO POINT ptlBrushOrigin; // la nesemnat flb [ ]: // IbO RECT VisRectRegion://lb } DCAttr; Semnificația majorității câmpurilor structurii DC ATTR este clară, fără explicații Când obiectele GDI (cum ar fi pensule, pixuri și fonturi) sunt selectate în contextul dispozitivului, mânerele lor sunt stocate în atributele lor respective Nu există nici măcar o urmă a prezenței rasterelor, paletelor și regiunilor dependente de dispozitiv în structură Atributele scalare (culoarea textului, culoarea fundalului, modul grafic, operarea bitmap, modul stretch blitting, tipul de justificare a textului și modul de afișare) sunt de asemenea stocate în această structură Unele atribute (culoare și alinierea textului) sunt stocate în duplicat dintr-un motiv necunoscut Windows NT/ GDI acceptă transformări mondiale între sistemele de coordonate logice și fizice Transformările lumii efectuează transformări de translație, scară, rotație și forfecare Transformarea lumii este descrisă de o matrice XFORM x reală, transmisă la apelarea funcției SetWorldTransform Matricea XFORM nu este stocată în structura de date DC ATTR direct în format virgulă mobilă XFORM constă din șase numere reale de precizie simplă care descriu o transformare liniară în plan Se știe că reprezentarea standard a numerelor reale cu precizie simplă în format IEEE are octeți, în timp ce reprezentarea cu precizie dublă a unui număr conține octeți Cu toate acestea, reprezentarea XFORM în DC ATTR nu utilizează niciunul dintre aceste două formate XFORM este reprezentat de o structură MATRIX constând din șase perechi DWORD și trei numere de de biți Cel mai apropiat analog de aceste perechi DWORD este structura FLOATOBJ, care este definită în WinNT DDK Un număr real cu o singură precizie în format IEEE este format din de biți Conține un bit semn, un exponent de biți cu un offset de și o mantisă de de biți cu un bit ascuns, care este întotdeauna Un număr real este calculat prin semnul formulei * A(exlonent- ) * ( " + mantisa) A De exemplu, numărul este stocat ca x F Bitul semn este pozitiv, exponentul este și toți biții mantisei sunt zero Conform formulei de mai sus, obținem: * ^ ( - ) * ( " + ) / A \u d Microsoft simulează calcule cu valori reale cu aritmetică întregă cu „viteză mare” și precizie Precizia ridicată înseamnă o mantisă lungă, iar viteza este obținută prin construirea unui format din care componentele unui număr sunt ușor de extras în timpul calculelor Capitolul Structuri interne de date GDI/DirectDraw Pentru a reprezenta numere reale în GDI, Microsoft folosește structura FLOATOBJ Această structură este împărțită în două numere de de biți: dword înalt (u! ) definește exponentul, iar dword scăzut (ull) definește mantisa plus bitul de semn Spre deosebire de formatul IEEE, biții ascunși sau offset-urile nu sunt utilizați în FLOATOBJ Convertirea unei structuri FLOATOBJ într-un număr real este foarte ușoară: dublu FL AT BJ Dublu (const FLOATOBJ & f) { return (dublu) f ull * pow( , (dublu)f ul - )): } De exemplu, când reprezintă numărul în format FLOATOBJ, câmpul ul este și câmpul ull este x Aceste două numere sunt ușor convertite la valoarea inițială A * A( - ) = Pe lângă reprezentarea XFORM în format FLOATOBJ, GDI stochează și versiuni rotunjite ale offset-urilor (eDx și eDy) în câmpurile întregi XFORM eDxI și XFORM eDyI Structura DC ATTR conține multe câmpuri, al căror sens rămâne un mister pentru noi În același timp, multe funcții de context ale dispozitivului nu modifică direct ATTR-ul DC; de exemplu, apelurile către SelectPal ette, SetMiterLimi t și SetArtDi rection nu modifică conținutul DC ATTR După cum va fi arătat mai jos, DC ATTR este doar o parte dintr-o structură de date mai complexă susținută de GDI pentru un context de dispozitiv Structura de date din contextul dispozitivului, stocată în spațiul de adrese kernel, conține o copie în oglindă a structurii DC ATTR cu o mulțime de informații suplimentare despre driverul de dispozitiv care suportă contextul Pentru a recapitula, în această secțiune, am analizat structurile de date disponibile în modul utilizator pentru obiectele perie uniformă, regiune dreptunghiulară, font și context dispozitiv Aceste structuri de date sunt destul de simple și sunt destinate în principal să optimizeze performanța GDI atunci când se comută frecvent între privilegiile modul utilizator și modul kernel Pentru a înțelege mai bine structurile interne de date ale GDI, este necesar să se analizeze restul structurilor de date disponibile în modul kernel NOTĂ - - Pe sistemele cu procesor Intel, nu este recomandat să folosiți calcule reale și instrucțiuni MMX în componentele în modul kernel, deoarece starea acestor operațiuni nu este salvată prin comutatoarele de sarcini Acesta este unul dintre motivele pentru care GDI reprezintă numerele reale ca două numere întregi pe de biți Un alt motiv este viteza pe computere cu suport insuficient de rapid sau complet absent pentru calcule reale Motorul grafic Windows NT/ conține zeci de funcții care emulează operații reale - FLOATOBJ-Add, FLOATOBJ GreaterThan etc Pe noile procesoare din familia Intel, operațiunile reale pot fi efectuate cu aceeași viteză ca și cele întregi, dar conversia de un număr real la un întreg apare relativ lent Windows include câteva caracteristici noi care permit driverului să salveze contextul de calcul curent și să utilizeze suport hardware pentru operațiuni reale și MMX în modul kernel Accesarea spațiului de adrese în modul Kernel Accesarea spațiului de adrese în modul Kernel Primul nostru pas către descifrarea structurilor de date GDI în modul kernel este să putem citi date din spațiul de adrese în modul kernel într-un program în modul utilizator (cum ar fi GDIHandle) În Windows NT/ , fiecărui proces i se acordă gigaocteți de spațiu de adrese, dar numai cei gigaocteți de jos sunt accesibili din programele în modul utilizator Primii doi gigaocteți sunt inaccesibili programelor în modul utilizator pentru citire, scriere sau execuție Orice încercare de a accesa primii gigaocteți ai spațiului de adrese direct dintr-un program în modul utilizator generează o eroare de securitate hardware Chiar și depanatorul Microsoft Visual C++ este un program în modul utilizator Din acest motiv, nu permite, de exemplu, obținerea de date la OxE sau trecerea printr-un DLL în mod kernel (cum ar fi win k sys) Depanatoarele mai puternice, cum ar fi Numega Softce/W, sunt furnizate de drivere în modul kernel Dacă ați mai lucrat cu Softlce/W, este posibil să fi observat că la pornirea manuală Softlce/W, apare pentru scurt timp o fereastră DOS cu comanda net start ntice Această comandă încarcă DLL ntice sys în modul kernel în spațiul de adrese ale nucleului și creează un nou dispozitiv, o componentă în modul utilizator cu care interacționează Softlce/W Driverele în modul kernel sunt DLL-uri speciale construite conform anumitor reguli De exemplu, driverele în modul kernel nu pot apela funcții Win API deoarece punctele lor de intrare sunt situate în spațiul de adrese al utilizatorului Driverele în modul kernel sunt încărcate în spațiul de adrese kernel, unde programele pot funcționa pe toți cei gigaocteți de spațiu de adrese Majoritatea driverelor de dispozitiv Windows NT acceptă operațiuni I/O care sunt modelate ca operațiuni cu fișiere Aceste drivere pot fi accesate folosind API-ul Win apelând Create-File, ReadFile, WriteFile sau funcția DeviceloControl, mai puțin cunoscută De exemplu, folosind operațiuni cu fișiere, puteți lucra cu portul serial, portul paralel și driverele sistemului de fișiere În plus, Win oferă un set de funcții pentru încărcarea, pornirea, oprirea și închiderea driverelor de dispozitiv prin interfața de serviciu API Frumusețea acestei soluții este că driverul de dispozitiv nu trebuie să corespundă unui dispozitiv fizic real, cum ar fi un port paralel sau USB (Universal Serial Bus) Puteți crea un dispozitiv imaginar, puteți scrie un driver pentru acesta, îl puteți instala cu o funcție API Win și apoi puteți lucra cu el utilizând operațiuni cu fișiere Win Arhitectura driverelor de dispozitiv Windows NT/ vă permite să rezolvați tot felul de sarcini dificile care nu sunt rezolvate doar de instrumentele Win Tot ceea ce este necesar în stadiul actual al cercetării noastre este capacitatea de a citi date din spațiul de adrese kernel Dacă luăm în considerare un spațiu de adrese de gigaocteți ca un disc virtual, putem scrie pentru el Capitolul Structuri interne de date GDI/DirectDraw un driver care vă va permite să citiți orice bloc de memorie și să îl transmiteți unei aplicații în modul utilizator De obicei, un driver de dispozitiv I/O în mod kernel Windows NT/ conține un singur punct de intrare, DriverEntry, care este apelat când driverul este încărcat: Driver NTSTATUS DrlverEntrydN PDRIVER OBJECT, ÎN PUNICODE STRING RegistryPath) Funcția DriverEntry servește același scop ca DllMainStart-CRTStartup, punctul de intrare într-un DLL în modul utilizator Cu toate acestea, spre deosebire de DLL-urile în modul utilizator, driverele în modul kernel nu exportă de obicei funcții În schimb, DriverEntry spune sistemului adresele funcțiilor care urmează să fie exportate de sistem, folosind structura DRIVER-OBJECT Un simplu driver I/O poate fi limitat la implementarea unui subset minim de funcții De exemplu, următorul fragment DriverEntry exportă două funcții Funcția DrvUnload este apelată când driverul este descărcat Funcția de spatch DrvDi este apelată atunci când DeviceloControl este creat, închis și apelat Driver->DriverUnload = DrvUnload: Dri ver->MajorFuncti on[IRP MJ CREATE] = Spatch DrvDi: Driver->MajorFuncti on[IRP MJ CLOSE] » Spatch DrvDi: Driver->MajorFunctionCIRP MJ DEVICE CONTROL] = DrvDispatch: Pentru a ne atinge obiectivul de a citi datele din spațiul de adrese kernel în modul utilizator, avem nevoie de un driver de dispozitiv simplu Să-i spunem Periscop Funcția principală a driverului este de a procesa cererea DeviceloControl În parametrul DeviceloControl sunt transmise adresa de pornire și dimensiunea blocului de date de citit Periscope citește datele în modul kernel și le stochează într-un buffer accesibil din modul utilizator la ieșirea din DeviceloControl Mai jos este codul sursă complet pentru driverul Periscope - „periscopul” prin care vom monitoriza funcționarea nucleului #include „kernelopt h” #include „periscope h” const WCHAR DeviceNameE] = L"\\Dispozitiv\\Periscope": const WCHAR DeviceLink[] » L”\\DosDevices\\PERISCOPE”: // Gestionarea CreateFile, CloseHandle NTSTATUS DrvCreateCloseUN PDEVICE OBJECT DeviceObject IN PIRP Irp) { Irp->IoStatus Information = ; Irp->IoStatus Status = STATUS SUCCESS: loCompleteRequest(Irp IO NO INCREMENT): returnează STATUS-SUCCESS; } // Manipularea DeviceloControl NTSTATUS DrvDeviceControl(IN PDEVICEJDBJECT DeviceObject, IN PIRP Irp) Accesarea spațiului de adrese în modul Kernel { NTSTATUS nStatus = STATUSJNVALIDJARAMETER; Irp->IoStatus Information = ; // Obține un pointer către poziția curentă a stivei // care conține coduri de funcție și parametri PIO STACK LOCATION irpStack » IoGetCurrentIrpStackLocation(Irp): nesemnat * ioBuffer = (nesemnat *) Irp->AssociatedIrp SystemBuffer; if ( (irpStack->Parameters DeviceIoControl loControlCode == IOCTL PERISCOPE) && (ioBuffer!=NULL) && (eu rpStack->Parameters DeviceloControl InputBufferLength >= ) ) { lungime nesemnată » ioBuffer[l]; if ( irpStack->Parameters DeviceloControl OutputBufferLength >- lungime) { Irp->IoStatus Informatlon - lungime; nStare - STATUS SUCCESS: încerca { metncpydoBuffer, (void *) oBuffer[ ] lungime); } cu excepția ( EXCEPTION EXECUTE HANDLER ) { Irp->IoStatus Information » ; nStare = STATUS NVALID PARAMETER; } } } Irp->IoStatus Status = nStatus: loCompleteRequestUrp IO NO INCREMENT): returnează nStatus; } // Se gestionează descărcarea șoferului void DrvUnloaddN PDRIVER OBJECT DriverObject) { UNICODE-STRING deviceLinkUnicodeString; RtlInitUnicodeString(&deviceLinkUnicodeString, DeviceLink): loDel eteSymboli cLi nk(&devi ceLi nkUni codeString): IoDeleteDevice(DriverObject->DeviceObject): Capitolul Structuri interne de date GDI/DirectDraw // punctul de intrare de inițializare // pentru driverele instalabile Driver NTSTATUS DrlverEntryUN PDRIVER OBJECT, ÎN PUNICODE STRING RegistryPath) UNICODE-STRING devlceNamellnicodeStrlng: Rt InitUnicodeString( &deviceNameUn codeStrlng, DevIceName ); // Creați dispozitiv PDEVICE OBJEST devIceObject = NULL: NTSTATUS ntStatus = loCreateDevIce(Driver, sizeof(KDevlceExtension) & devlceNameUnlcodeStrlng, FILE DEVICE PERISCOPE, TRUE &deviceObject); Dacă ( NT SUCCESS(ntStatus) ) { // Creați o legătură simbolică unde aplicațiile Win // va accesa driverul/dispozitivul UNICODE STRING devlceL nkUnlcodeStrlng: RtlInitUnicodeString(&deviceL nkUn codeString, DeviceLink); ntStatus = IoCreateSymbol cL nk( &dev ceLInkUnlcodeStrlng, &deviceNameUnicodeStrlng): // Creați tabelul de expediere a driverului Dacă ( NT SUCCESS(ntStatus) ) { Driver->DriverUnload = DrvUnload: Driver->MajorFunction[IRP MJ CREATE] = DrvCreateClose; Driver->MajorFunction[IRP MJ CLOSE] = DrvCreateClose; Drlver->MajorFunction[IRP MJ DEVICE CONTROL] = DrvDevIceControl: } } Dacă ( !NT SUCCESS(ntStatus) && deviceObject!=NULL ) loDeleteDevice(deviceObject): returnează ntStatus: } Cea mai mare parte a codului este „scheletul” driverului de bază în modul kernel Fiecare dispozitiv suportat de un driver trebuie să aibă un nume; în exemplul nostru, este folosit numele Periscope Acest nume este introdus în directorul Dispozitiv al spațiului de nume obiect Windows DDK include un mic utilitar, objdir, care, printre altele, listează driverele de dispozitiv instalate pe sistemul dumneavoastră Funcția DrvCreateClose se ocupă de crearea și închiderea instanțelor dispozitivului inițiate de apelurile la funcțiile API CreateFile și CloseHandle Funcția DrvDevIceControl rezolvă sarcina principală - citirea unui bloc de memorie atunci când DeviceloControl este apelat într-o aplicație utilizator Tot codul „interesant” este concentrat în câteva rânduri ale funcției DrvDevice-Control După verificarea faptului că a fost transmis codul corect în apel, tamponul Accesarea spațiului de adrese în modul Kernel input-output nu este gol, iar lungimea parametrului transmis este de cel puțin octeți, programul primește adresa de pornire și dimensiunea blocului de citit și apoi pur și simplu copiază datele solicitate în bufferul de ieșire Vă rugăm să rețineți că procesul de citire este protejat de un mecanism de gestionare a excepțiilor - în cazul în care orice adrese se dovedesc a fi nevalide Funcția DrvUnload se ocupă de descărcarea șoferului, iar funcția DriverEntry este punctul de intrare principal al șoferului Pentru ca codul de mai sus să se compileze corect în driverul în modul kernel, trebuie să modificați unele opțiuni implicite ale compilatorului și linkerului De exemplu, compilatorul trebuie să respecte convenția de apelare stdcall în loc de convenția de apelare implicită cdecl Indicatorul subsistemului Windows din driver ar trebui să fie „native, ” în loc de GUI Windows Aceste modificări sunt furnizate prin includerea opțiunilor corespunzătoare în fișierul de proiect și fișierul antet kernelopt h Cu setările corecte, driverul în modul kernel se va compila cu succes în Visual C++ Programul Periscope este compilat într-un mic DLL în mod kernel, Periscope sys În următoarele programe, se presupune că acest DLL este copiat în directorul rădăcină al unității C: Driverul este scris și testat pe sistemele Windows NT /Windows Încărcarea dinamică, pornirea, oprirea și descărcarea driverelor de dispozitiv în modul kernel sunt bine acceptate la nivelul API Win Pentru a îndeplini aceste funcții, am definit clasa KDevice C++ Constructorul KDevice stabilește o conexiune la managerul de control al serviciului apelând funcția OpenSCMMânager Funcția publică KDevice: :Load încarcă driverul cu funcția CreateService, pornește driverul cu funcția StartService și apoi obține mânerul obiectului dispozitiv cu funcția CreateFile Când apelați CreateFile, șirul \\ \Periscope este specificat ca nume de fișier, care este denumirea standard pentru dispozitivul care urmează să fie deschis în Windows După aceea, puteți apela funcția DeviceloControl de pe manipulatorul rezultat și puteți comunica cu driverul Periscope care rulează în modul kernel KDevice este o clasă generică pentru lucrul cu driverele de dispozitiv Windows NT/ Cu același succes, îl poți folosi în relație cu un alt șofer Clasa KDevice este simplă, așa că nu ne vom uita la codul sursă complet și vom trece direct într-un mic program de testare pentru a funcționa cu driverul Periscope // TestPeriscope cpp #define STRICT # nclude #include #indude #include „devlce h” #include „ APeriscopeWPeriscope h” clasa KPeriscopeClient : KDevice public { public: KPeriscopeClient(const TCHAR * DeviceName) : KDevice(DeviceName) Capitolul Structuri interne de date GDI/DirectDraw { } bool Read(void * dst, const void * src, len nesemnat): }: bool KPerlscopeCllent::Read(void * dst const void * src len nesemnat) { unsigned cmd[ ] = { (nesemnat) src len}: nesemnat lung dwRead: return loControl(IOCTL-PERISCOPE cmd slzeof(cmd) dst len &dwRead) && (dwRead==len): } Int WINAPI W nMa n(HINSTANCE HINSTANCE LPSTR, Int) { Domeniul KPerlscopeCl ent ("PerlScope"): Dacă ( scope Load("c:\\per scope sys")==ERROR SUCCESS ) { nesemnat char buf[ ]: scope Read(buf (void *) xa E slzeof(buf)): domeniul de aplicare CIose(): MessageBox(NULL (car *) buf „Meni[ xa e]” MB OK); } el se MessageBox(NULL, nume complet „Nu se poate încărca c:Wper scope sys” NUL MB OK): întoarce ; } Programul creează o clasă KPerlscopeCllent derivată din KDevice și include o metodă Read suplimentară, care este un wrapper pentru apelarea DeviceloControl Această metodă îi spune Periscope să citească un bloc de memorie folosind codul de control special IOCTL PERISCOPE Programul principal instanțiază un KPeri scopeClient pe stivă, încarcă driverul în modul kernel și citește de octeți începând cu adresa x e Adresa aparține motorului grafic win k sys care alimentează gdi dll și user dll Adresa de bază a win k sys este OhaOOOOOOOO Citirea la offset x e de la începutul unui modul Win returnează de obicei un avertisment DOS la executarea unui npo-gram Windows: „Acest program nu poate fi rulat în modul DOS $” Dacă este prima dată când lucrați cu textul unui driver simplu pentru modul kernel Windows NT/ și instrumentele rudimentare pentru a lucra cu driverul din modul utilizator, probabil că veți fi tentat să parcurgeți codul și să vedeți cum funcționează lucrurile cu adevărat Înarmați-vă cu un depanator la nivel de kernel (cum ar fi Softlce/W), încărcați simbolurile necesare sau exportați tabelul de funcții pentru DLL-urile de sistem, WinDbg și extensia GDI Debugger treceți de la funcția WinMain din TestPeriscope cpp la funcția DrvDeviceControl din Periscope cpp Veți ajunge la starea stivei prezentată în tabel Rețineți că, între introducerea funcției DeviceloControl în kernel dll și ajungerea la DrvDeviceControl în Periscope, rulează codul de sistem Windows, așa că va trebui să treceți prin assembler De asemenea, trebuie remarcat faptul că ntdll dll este un DLL în modul utilizator, iar întreruperea Eh este apelată pentru a comuta procesorul în modul de adresare a nucleului Cu alte cuvinte, întreruperea Eh este deservită de codul modului kernel Tabelul Stack stare la trecerea de la un program în modul utilizator la un driver în modul kernel Level Funcție Modul/fișier WinMain TestPeriscope cpp KPeriscopeClient::Citiți TestPeriscope cpp KDevice::IoControl Device h DeviceloControl Kernel dll NtDeviceloControlFile Ntdll dll Int Eh NTDevi celoControlFi și Ntoskrnl exe lofCallDriver Ntoskrnl exe DrvDeviceControl Periscope cpp WinDbg și extensia GDI Debugger Capacitatea de a accesa datele în modul kernel Windows este un bun punct de plecare pentru cercetarea structurilor de date kernel, dar necesită cunoașterea unde să căutați informații și cum să le decodați, ceea ce necesită o bună cunoaștere a nucleului Windows Microsoft rămâne cea mai autorizată sursă de informații despre kernel-ul Windows Pe baza acestui lucru, vom apela la setul de instrumente oficial Microsoft și vom încerca să înțelegem structurile de date GDI cu ajutorul acestuia Windows Platform SDK și Windows NT/ DDK includ un utilitar puternic de depanare grafică pentru aplicațiile Win și driverele Windows NT/ în mod kernel, inclusiv capacitatea de a examina depozitele de blocare și datele de pe ecranul albastru Acesta este Microsoft Windows System Debugger (WinDbg) Cea mai bună parte este că acest program este gratuit Există mai multe moduri de a utiliza WinDbg A Pentru a depana aplicațiile Win pe aceeași mașină ca un depanator obișnuit în modul utilizator, cum ar fi depanatorul Microsoft Visual C++ Capitolul Structuri interne de date GDI/DirectDraw În acest mod, nu veți putea să introduceți codul modului kernel și să lucrați cu datele din modul kernel A Pentru depanarea de la distanță a aplicațiilor Win , similar instrumentelor de depanare la distanță din depanatorul Visual C++ În acest mod, calculatoarele master și slave sunt conectate printr-un cablu nul, printr-un modem sau printr-o rețea Lucrați cu interfața WinDbg pe computerul gazdă și depanați programul care rulează pe computerul slave În acest caz, numai modul utilizator este disponibil pentru depanator A Pentru depanarea de la distanță a codului modului kernel Windows NT/ , similar instrumentelor de depanare a nucleului Softlce/W În acest mod, computerele master și slave sunt conectate printr-un cablu nul Calculatorul slave pornește într-o configurație specială cu depanarea nucleului activată WinDbg rulează pe computerul gazdă și gestionează programe pe computerul slave În modul de depanare la distanță a nucleului, computerul gazdă are acces la întregul spațiu de adrese de GB al computerului slave În domeniul depanării codului în modul kernel, depanatorul Softlce/W este mult mai convenabil, deoarece are nevoie doar de un computer, în timp ce WinDbg are nevoie de un computer gazdă suplimentar În plus, Softlce/W facilitează trecerea de la codul în modul utilizator la codul în modul kernel și invers Pe de altă parte, WinDbg este superior Softce/W în unele zone pur și simplu pentru că este un program oficial dezvoltat de Microsoft Depanatorul WinDbg este mic, gratuit și acceptă diferite versiuni de Windows NT/ , în timp ce Softce/W costă o mulțime de bani și necesită actualizări frecvente când sunt lansate versiuni noi de Windows NT/ Cea mai remarcabilă caracteristică a depanatorului WinDbg este arhitectura sa modulară, extensibilă Depanatorul obișnuit acceptă un set limitat de comenzi pentru accesarea datelor și codului, setarea punctelor de întrerupere, controlul execuției programului și așa mai departe WinDbg vă permite să includeți noi comenzi în depanator prin scrierea unei extensii DLL de depanare Fiecare extensie DLL este de obicei specializată într-o zonă specifică a sistemului de operare Windows Distribuția WinDbg include extensii DLL dezvoltate de Microsoft (Tabelul ) Tabelul Extensiile Microsoft WinDbg Debugger Funcționalitate extinsă a sistemului de operare Gdikdx dll GDI Kernel Mode Kdextx dll Executabil/HAL, modul kernel Extensia mod utilizator standard Ntsdexts dll Rpcexts dll Apel de procedură de la distanță (RPC) Userexts dll UTILIZATOR, modul utilizator Userkdx dll UTILIZATOR, modul kernel Vdmexts dll NT DOS/WOW (Fereastra în fereastră) WinDbg și extensia GDI Debugger Interfața WinDbg cu extensii de depanare este organizată foarte simplu, este complet definită în fișierul antet DDK WDBGEXTS h Extensiile de depanare trebuie să exporte cele trei funcții necesare CheckVersion, ExtensionApiExtension și WinDbgExtensionDllInit care efectuează verificarea și inițializarea versiunii Funcția CheckVersion se asigură că versiunea sistemului de operare de pe computerul slave se potrivește cu versiunea pentru care este scrisă extensia Nu vă așteptați să obțineți rezultate corecte când încărcați versiunea GRATUITĂ a DLL a extensiei de depanare pe o versiune VERIFICATĂ a sistemului de operare Funcția ExtensionApiVerion verifică dacă DLL-urile de extensie și gazda WinDbg utilizează aceeași versiune API Funcția WinDbgExtensionDllInit, cea mai importantă dintre aceste trei funcții, transmite structura WINDBG EXTENSION APIS de la WinDbg la extensia DLL În prezent, structura APIS WINDBG EXTENSION definește funcții de indirectă AND care pot fi apelate dintr-o extensie DLL Implementarea funcțiilor de apel indirect implică DLL imagehlp, fișiere de depanare cu nume simbolice și un sistem slave conectat printr-un cablu nul typedef struct WINDBG EXTENSION APIS { ULONG PWINDBG OUTPUT ROUTINE PWINDBG GET EXPRESSION PWINDBG GET SYMBOL PWINDBG-DISASM PWINDBG CHECK CONTROL C PWINDBG READ PROCESS MEMORY ROUTINE PWINDBG WRITE PROCESS MEMORY-ROUTINE PWINDBG GET THREAD CONTEXT ROUTINE PWINDBG SET THREAD CONTEXT ROUTINE PWINDBGOUT IECT PWINDBG STACKTRACE ROUTINE } WINDBG EXTENSION APIS, *PWINDBG EXTENSION APIS; nDimensiune: IpOutputRoutine: pGetExpressi onRoutine: IpGetSymbolRoutine: IpDisasmRoutine; pCheckControlCRouti ne; pReadProcessMemoryRouti ne: pWr iteProcessMemoryRouti ne pGetThreadContextRouti ne: pSetThreadContextRouti ne: ploctlRoutine; IpStackTraceRoutlne; După cum puteți vedea din această definiție, DLL-urile de extensie pot accesa programul de control WinDbg cu solicitări de a tipări un șir, de a evalua o expresie, de a căuta un nume simbolic, de a dezasambla codul, de a verifica dacă există o blocare, de a citi/scrie conținutul memoriei, de a citi/scrie contextul firului, apel de intrare-ieșire și chiar o urmărire a stivei Cu alte cuvinte, toate informațiile despre structura structurilor interne de date ale sistemului de operare se află în extensia DLL, iar WinDbg oferă o interfață de utilizator cu sistemul depanat Pe lângă cele trei funcții necesare, extensia DLL poate exporta și alte funcții care pot fi folosite ca comenzi pe linia de comandă WnDbg Numele funcției exportate este același cu numele comenzii Toate funcțiile exportate au același prototip definit de următoarea macrocomandă: #define DECLARE API(e) \ CPPMOD VOID\ s(\ HANDERE hCurrentProcess \ HANDERE hCurrentThread, \ ULONG dwCurrentPc,\ Capitolul Structuri interne de date GDI/DirectDraw ULONG dwProcessor, \ PCSTR args \ ) Deoarece cartea este despre programarea grafică Windows NT/ , suntem interesați în primul rând de Gdikdx dll, o extensie DLL pentru depanarea GDI în modul kernel După configurarea WinDbg, extensia Gdikdx dll este încărcată cu comanda oad pe linia de comandă WinDbg: > încărcați gdikdx dll Biblioteca de extensii de depanare Asystem \gdikdx] a fost încărcată Toate comenzile de extensie de depanare încep cu un ! pentru a le distinge de comenzile standard WinDbg Comanda de ajutor afișează un rezumat al zecilor de comenzi acceptate de extensia de depanare GDI După cum v-ați aștepta de la un instrument intern de depanare, această comandă scoate informații învechite pentru gdikdx dll În special, comenzile brush, cliserv, gdicaii și proxymsg sunt listate în ajutor, dar nu sunt de fapt acceptate; comanda di fi a fost înlocuită cu comanda ifi, iar noile comenzi dbli și ddib nu sunt menționate deloc Din fericire, fiecare comandă are un parametru ■? care poate fi folosit pentru a obține informații actualizate Referindu-ne la lista de funcții exportate de gdikdx dll, veți găsi nume de comenzi noi care nu sunt în ajutor Comenzile de extensie de depanare pentru depanarea GDI în modul kernel sunt listate în Tabelul Tabelul Comenzi de extensie de depanare pentru GDI în modul Kernel Utilizarea opțiunilor de comandă dumphmgr [?] Rezumatul obiectelor GDI după tip dumpobj [?] [-p pid] [- ] [-s] objecttype Toate obiectele GDI de tipul dat dumpdd Obiecte Manager DirectDraw Manipulator dumpddobj [-P pid] [tip] Obiecte DirectDraw de tipul dat dh [-?] mânerul obiectului intrarea HMGR pentru obiectul GDI dht [-?] mâner de obiect Tip/unicitate/index pentru mânerul GDI ddib [-?] [- LPBITMAPINFO] [-w Lățime] [-h Înălțime] [-f nume fișier] [-b Biți] [-y Byte Width] [•p palbits palsize] pbits Dump raster dbli [•?] BLTINFO * ddc [■îadeghrstuvx] hdc Contextul dispozitivului dpdev [■TabdfghmnprRw] ppdev Obiect dispozitiv fizic dldev [■?] [-f] [-F #] Obiect LUN Idev WinDbg și extensia GDI Debugger Utilizarea opțiunilor de comandă dgdev E-?m] dgdevptr DISPOZIT-GRAFIC dco [-?] clipobj CLIPOBJ dpo [-?] pathobj PATHOBJ dppal [■?] pal EPALOBJ dpw [-?] [proces] dpbrush [-?] pbrush | hbrush HBRUSH sau PBRUSH dfloat [-?] [- num] Valoare Dumpează numărul real sau matrice în format IEEE ebrush [-?] pbrush|hbrush HBRUSH sau PBRUSH dpso [-?] [-f nume fișier] surfobj Structura SURFACE din SURFOBJ dblt [-?] BLTRECORD PTR BLTRECORD dr [-?] hrgn|prgn REGIUNE cr [•?] hrgn|prgn Verificați REGIUNEA dddsurface [-?haruln]ddsurface EDD-SURFACE dddlocal [-?ha] EDD DIRECTDRAW LOCAL dddglobal [■?ha] EDD DIRECTDRAW GLOBAL dsprite E-?ha] SPRITE dspritestate E-?ha] SPRITE STATE rgnlog [-?] nnn[sl][s ][s ][s ] Ultimele nnn intrări rgnlog statistici [-?] Statistici acumulate veri fier E-?hds] Afișează informații despre verificator hdc [■?gltf] mâner dcl [-?] DCLEVEL* dea [-?] DC ATTR* Ieșire structură de date HDC în modul utilizator ca E-?]AJUSTARE CULOARE* mix [-?]MATRIX* Ieșire MATRIX de la DC ATTR la [-?]LINEATTRS* efE-?]adresă [număr] dteb [-?] TEB Emite comenzi din coada TEB dpeb [-?] Ew] Ieșire obiecte PEB în cache Continuare Capitolul Structuri interne de date GDI/DirectDraw Tabelul Continuare Utilizarea opțiunilor de comandă cu [-?] adresa [număr] ho [-?] EXFORMOBJ* Extensii de font tstats [-?] [ ] gs [-?] FDGLYPHSET* gdata [-?] GLYPHDATA *elf tm [-?] TEXTETRICW* tmwi [-?]TMW INTERNAL* pentru [-Tacfhwxy] FONTOBJ* pfe [■?] PFE* pff [-?] PFF* pft [-?] PFT* stro [?phe] STROBJ* gb [-?hmg] GLYPHBITS* gdf [-?] GLYPHDEF* gp [-?] GLYPHPOS* cache [■?] CACHE* fh [-?] FONTHASH* hb [-?] HACHBUCKET* fv [-?] FILEVIEW* ffv [-?] FONTFILEVIEW* sfer [-?] ifi [-?] IFIMETRICS* pubft [-?] Eliminați toate fonturile deschise pvtft [-?] Eliminați toate fonturile private sau încorporate devft [-?] Eliminați toate fonturile dispozitivului dispcache [-?] Eliminați memoria cache a glifului pentru ieșirea structurii PDEV Probabil că ești dornic să conectezi un al doilea computer printr-un modem nul și să încerci aceste comenzi uimitoare despre care nu știai că există Autorul a trecut deja prin toate acestea Chiar daca tu WinDbg și extensia GDI Debugger Dacă puteți configura corect sistemele master și slave, le puteți conecta și rula WinDbg pe computerul master pentru a controla computerul slave, nu este ușor să utilizați comenzile de extensie GDI Multe dintre ele funcționează cu mânere de obiect GDI sau pointeri către structuri de date specifice Pentru a utiliza aceste comenzi, trebuie să faci multă muncă pentru a analiza sistemul slave și a obține manipulatoarele de obiecte sau pointerii necesare Cu toate acestea, cercetarea GDI necesită o abordare creativă și neconvențională Nu este posibil să se creeze un înlocuitor simplu pentru WinDbg, destinat nu pentru depanare generală, ci doar cu scopul de a înțelege mai bine Windows NT/ GDI? Pentru a face acest lucru, avem nevoie de o aplicație simplă care gestionează o extensie DLL GDI care rulează pe o singură mașină Încercați să vă imaginați comanda dumphmgr a extensiei GDI care afișează un rezumat al tabelului de obiecte GDI pentru computerul slave de pe gazdă Procesul arată cam așa WinDbg încarcă gdikdx dll pe computerul gazdă la cererea utilizatorului Când utilizatorul introduce comanda ! dumphmgr, WinDbg îl transmite funcției dumphmgr exportată de gdikdx dll Funcția dumphmgr a bibliotecii gdikdx dll apelează WinDbg cu o solicitare pentru a obține valoarea variabilei globale win k sys care conține adresa tabelului de obiecte GDI în spațiul de adrese kernel Sarcina este rezolvată folosind funcțiile de apel indirect transmise către Gdikdx dll de la WinDbg WinDbg folosește IMAGEHLP API pentru a obține o adresă dintr-un nume simbolic Nu uitați: fișierele simbolice de depanare pentru slave trebuie instalate pe gazdă, astfel încât WinDbg are acces deplin la informațiile de depanare ale slave Gdikdx apelează WinDbg cu o solicitare de a citi valoarea unei variabile care conține un pointer către tabelul de obiecte GDI la adresa variabilei din spațiul de adrese al gazdei WinDbg trimite o cerere de modem nul către computerul slave Solicitarea este deservită de gazda care rulează în modul de depanare Gdikdx apelează WinDbg pentru a citi întregul tabel de obiecte GDI la adresa sa de pornire WinDbg trimite cererea înapoi la computerul slave Gdikdx procesează datele primite și apelează WinDbg cu o solicitare de afișare a informațiilor în fereastră WinDbg, ca program care controlează funcționarea extensiei GDI gdikdx dll, oferă două funcții principale - transmiterea comenzilor către gdikdx dll și deservirea funcțiilor de apel indirect Trimiterea comenzilor către gdikdx dll este foarte ușoară; WinDbg transmite mânerele curente ale procesului și ale firului de program, contorul de program al procesorului, numărul de procese de pe procesorul slave și linia de comandă completă către funcția exportată Menținerea funcțiilor de indirectare la prima vedere pare o sarcină descurajantă, deoarece există funcții de indirectare diferite De fapt, gdikdx dll Capitolul Structuri interne de date GDI/DirectDraw folosește doar câteva dintre ele Cea mai mare parte a dificultăților apare cu funcția de citire a memoriei procesului, situată în spațiul de adrese al nucleului Din fericire, aveți Periscope, driverul pentru modul kernel creat în secțiunea anterioară Să încercăm să scriem un mic program de control pentru gdikdx dll Programul Fosterer este simplu; este un program cu o interfață cu utilizatorul prin care dezvoltatorul introduce comenzi Comenzile introduse sunt transmise extensiei de depanare GDI pentru execuție Când o extensie de depanare trebuie să decodeze un nume simbolic sau să citească un bloc de memorie, apelează la Fosterer pentru ajutor în același mod în care ar apela la WinDbg Următoarea listă arată declarația clasei KHost, care furnizează funcționarea funcțiilor de apel indirect clasa KHost { public: KlmageModule*pWin k; KPeriscopeClient *pScope: HWND hwndOutput; HWND hwndLog: HANDERE hProces: KHostO { pW n k=NULL: pScope=NULL: hwndOutput=NULL: hwndLog=NULL: hProcess=NULL: } void WndOutput(HWND hWnd const char * format va list argptr): void Log(const char * format ): void ExtOutput(const char * format, ): nesemnat ExtGetExpression(const char * expr): bool ExtCheckControlC(void): bool ExtReadProcessMemory(const void * adresa nesemnat*buffer număr nesemnat nesemnat lung * bytesread): }: Clasa KHost conține cinci variabile Pointerul pWin k indică o instanță a clasei KlmageModule care utilizează funcțiile imagehlp dll pentru a căuta informații simbolice în fișierele de depanare ale motorului grafic Windows win k sys Al doilea pointer, pScope, indică o instanță a clasei KPeriscope pentru a citi date din spațiul de adrese în modul kernel Primul mâner de fereastră aparține ferestrei de text principale, care imită fereastra de ieșire WinDbg Al doilea handle de fereastră este pentru stocarea informațiilor suplimentare despre utilizarea funcțiilor de indirectare în gdikdx dll Ultima variabilă de clasă, hProcess, conține mânerul procesului examinat Primele două funcții rezolvă sarcini auxiliare; WinDbg și extensia GDI Debugger sunt urmate de cinci funcții corespunzătoare celor cinci funcții de apel indirect pe care urmează să le implementăm Următoarea listă arată implementarea funcțiilor ExtGetExpression și ExtReadProcessMemory KHost nesemnat:;ExtGetExpression(const char * expr) { Dacă ((expr==NULL) || strlen(expr)==O ) { afirmă (fals): întoarce ; } Dacă ( (expr[ ]>=' ') && (expr[ ] ImageGetSymbol(expr+ ); el se pis = pWin k->ImageGetSymbol(expr); if ( pis ) { Log("GetExpression(%s)=% x\n" expr pis->Adresa); return pis->Adresa; } } ExtOutputC'Unknown GetExpression(,",%s"")\n" expr); aruncați „Expresie necunoscută”; întoarce ; } bool KHost;;ExtReadProcessMemory(const void * adresa, nesemnat*buffer număr nesemnat, nesemnat lung * bytesread) { dacă (pScope) { ULONG dwRead = : if ( (nesemnat) adresa >= x ) dwRead = pScope->Read(buffer adresa număr); el se ReadProcessMemory(hProcess adresa buffer număr & dwRead); Capitolul Structuri interne de date GDI/DirectDraw dacă (octeți citiți) * bytesread = dwRead: Dacă (adresă (nesemnată) >= x ) Jurnal("ReadKRam($ x, $d)=", adresa, număr): el se Jurnal("ReadURam(£x, £ x, fcd)=", hProcess, adresa, număr): int len = min( , count/ ); pentru (Int = ; ImageGetSymbol pentru a obține adresa dată cu numele dat, cum ar fi win k!gcMaxHmgr Pointerul pWin k indică un obiect KlmageModule care a fost preîncărcat cu informații de nume simbolice pentru fișierul win k sys Funcția KlmageModule: :ImageGetSymbol, care nu este listată în carte, apelează funcția SymGetSymFromName pentru a converti un nume simbolic într-o adresă Un detaliu interesant: atunci când este apelată, funcția SymGetSymFromName primește un pointer către un pointer non-constant către un șir, în timp ce ExtGetExpression ia doar un pointer constant către un șir ca parametru Apare o dorință naturală - de a converti un indicator constant într-unul non-constant, de a înșela compilatorul și de a-ți atinge scopul Nu va ieşi nimic din asta; apelul către SymGetSymFromName va eșua și veți primi o eroare de acces Ambele părți sunt serioase Funcția ExtGetExpression este apelată din biblioteca gdikdx dll, care este compilată în Visual C++ cu opțiunea de a muta toate liniile într-o secțiune numai pentru citire Prin urmare, șirurile transmise către ExtGetExpression trebuie să fie doar pentru citire Funcția SymGetSymFromName caută caracterul ! care separă numele modulului de numele funcției și îl înlocuiește cu un caracter nul pentru a asigura completarea corectă a numelui modulului Ca rezultat, va fi generată o eroare pentru un șir constant Problema este rezolvată simplu: înainte de a apela SymGetSymFromName, funcția Image-GetSymbol copiază parametrul într-o variabilă locală WinDbg și extensia GDI Debugger Funcția KHost: :ReadProcessMemory este responsabilă pentru citirea blocurilor de memorie În primul rând, se asigură că adresa aparține spațiului kernel Dacă verificarea reușește, funcția folosește clasa KPeriscopeClient (vezi secțiunea anterioară), care, la rândul său, folosește micul nostru driver în modul kernel Periscope sys; în caz contrar, funcția API Win ReadProcessMemory este apelată pur și simplu cu mânerul de proces Rețineți că, cu mânerul corect, funcția ReadProcessMemory vă permite să citiți conținutul spațiului de adrese în modul utilizator al altui proces Cu toate acestea, KHost este o clasă C++, în timp ce API-ul extensiei de depanare WinDbg este definit doar folosind facilitățile C Mai jos este o parte din codul rămas KHost theHost; vold WDBGAPI ExtOutputRout ne (format PCSTR ) { va stap; va start(ap format); theHost WndOutput(theHost hwndOutput format, ap); va end(ap); } ULONG WDBGAPI ExtGetExpressionIPCSTR expr) ( returnează theHost ExtGetExpression(expr); } void WDBGAPI ExtGetSymbolIPVOID offset PUCHAR pchBuffer PULONG pDeplasare) { arunca „GetSymbol nu este implementat”: } ULONG WDBGAPI ExtReadProcessMemory (adresă ULONG tampon PVOID ULONG număr PULONG bytescitit) { returnează theHost ExtReadProcessMemory( (const volum *)adresă (nesemnat*)buffer numara bytesread); WINDBG EXTENSION APIS ExtensionAPI = { sizeof(WINDBG EXTENSION APIS), ExtOutputRoutine ExtGetExpression ExtGetSymbol Capitolul Structuri interne de date GDI/DirectDraw ExtDisAsm, ExtCheckControl C, ExtReadProcessMemory, ExtWrlteProcessMemory, ExtGetThreadContext ExtGetThreadContext, ExtIOCTL ExtStackTrace }: Pentru a interacționa cu extensia de depanare, trebuie să populați structura WINDBG EXTENSION APIS cu informații despre funcțiile de indirectă ȘI Cinci dintre aceste funcții sunt mapate la funcții ale clasei KHost prin instanța globală a theHost Restul funcțiilor pur și simplu aruncă excepții, care sunt capturate de programul principal (dacă nu au fost prinse anterior în gdikdx dll) Textul arată doar o mică parte din programul Fosterer, dar în general este un program Windows destul de standard și simplu Programul principal creează mai multe ferestre copil; într-o fereastră, se introduce un handle de proces, în cealaltă, o comandă A treia fereastră face toate rezultatele principale În plus, este creată o fereastră suplimentară pop-up (pop-ir) pentru a afișa informații despre service Programul principal este responsabil pentru încărcarea driverului Periscope în modul kernel, a informațiilor de depanare win k sys și, cel mai important, a extensiei de depanare WinDbg gdikdx dll Inițializează gdikdx dll cu un tabel de funcții de apel indirect și verifică dacă versiunea curentă a sistemului de operare este compatibilă cu versiunea sistemului de operare a gdikdx dll Extensia de depanare GDI are o comandă dumphmgr foarte interesantă, cu care vom începe Această comandă ar trebui să afișeze informații generale despre mânerele GDI - adică același tabel de obiecte GDI pe care l-am căutat de atâta timp în acest capitol Dacă totul a fost configurat corect, tastați dumphmgr în fereastra de comandă, faceți clic pe butonul Do, închideți ochii și încercați să ghiciți ce sunteți pe cale să vedeți Ura! Lucrări! Am reușit să folosim cu succes gdikdx dll fără WinDbg, pe un singur computer, fără a rula sistemul de operare în modul de depanare, fără un modem nul - și am obținut un rezumat al conținutului tabelului de obiecte GDI din spațiul de adrese kernel! Mai mult, pentru ca programul Fosterer să funcționeze, nu trebuie să știm absolut nimic despre tabelul de obiecte GDI, deoarece extensia de depanare GDI are toate informațiile necesare Fereastra programului Fosterer este prezentată în fig Caseta mică din stânga afișează ID-ul procesului; în dreapta sus este câmpul de introducere a comenzii Comanda este transmisă extensiei de depanare GDI atunci când se face clic pe butonul Do Fereastra principală afișează rezultatele programului în sine și extensia de depanare GDI Câteva linii inițiale afișează starea de încărcare a driverului în modul kernel Periscope, fișierul de informații de depanare pentru motorul grafic și extensia de depanare GDI Extensiile de depanare sunt create cu Windows, deci li se atribuie același număr de versiune Programul se asigură că numărul de versiune al extensiei de depanare se potrivește cu același număr de sistem de operare și, dacă numerele diferă, afișează un avertisment Potrivirile exacte sunt rare, dar ar trebui să încercați să păstrați aceste numere cât mai aproape unul de celălalt Structuri de date în modul kernel yaie Hețp de ani ; Fosterer Periscope încărcat D:\WINNT \symbols\sys\ \win k dbg încărcat Sistemul de operare Windows v , versiunea „D:\WINNT \System \gdikdx dll” s-a încărcat *** Extensia DLL ( Free) nu se potrivește cu sistemul țintă ( Free) dumphmgr Max gestionează până acum Total Hmgr: Memorie rezervată Committed ulLoop- gcMaxHmgr- gcMaxHmgr- handles, (Locate TYPE curente maxime LAB alocate) Cur LAB Max DEFJIYPE , - , - , - - TIP DC , - , - , - - RGN TYPE , - , - , - - SURF TYPE , - , - , - - CLIOBJ TYPE , - , - , - - PAL TYPE , - , - , - - ICMLCS—TIP , - , - , - - LFONT TYPE , - , - , - - PFE TYPE , - , - , - - BRUSH TYPE , - , - , - - TOTALE , - , - , - - cObiecte neutilizate cObiecte necunoscute Orez Gestionarea extensiei WinDbg Debugger în Fosterer După informațiile de stare, sunt afișate rezultatele rulării comenzii dumphmgr Din ele se poate observa că managerul de manipulare GDI (un fragment de cod responsabil cu lucrul cu tabelul de obiecte GDI) a rezervat până la megaocteți în spațiul de adrese kernel, dar doar KB dintre aceștia au fost actualizați Din numărul maxim de manipulatoare GDI ( ) de la ultima repornire a computerului, nu a fost implicat simultan mai mult decât ISO În momentul în care comanda dumphmgr a fost procesată, erau în uz doar de obiecte GDI, iar restul de de mânere au fost create și apoi șterse obiecte Rezumatul obiectului GDI afișează numărul de contexte de dispozitiv, hărți de biți, palete, fonturi logice, pensule și așa mai departe prezente efectiv pe sistem Cu toate acestea, acest exemplu oferă doar o idee aproximativă a ceea ce se poate face cu extensia de depanare GDI Acest instrument joacă un rol critic în procesul de analiză a structurilor interne de date ale GDI Structuri de date în modul kernel Înarmat cu driverul de dispozitiv în modul kernel Periscope, extensia de depanare WinDbg gdikdx dll și un program simplu de control al extensiei de depanare Fosterer, puteți explora în sfârșit structurile de date GDI nedocumentate în modul kernel Windows NT/ Capitolul Structuri interne de date GDI/DirectDraw Tabel de obiecte GDI din motorul GDI După cum se arată în secțiunile anterioare, fiecare proces Win funcționează cu tabelul global de obiecte GDL În procesele utilizator, tabelul este doar pentru citire și se mapează la adrese diferite în procese diferite GDI are o funcție GdiQueryTable nedocumentată care returnează adresa tabelului obiect GDI pentru procesul utilizatorului curent Tabelul de obiecte GDI este de fapt gestionat de motorul grafic GDI Win k sys Este lizibil și scris de la o adresă fixă în spațiul de adrese kernel Tabelul obiect GDI este mapat la spațiul de adrese utilizator al fiecărui proces care funcționează cu facilitățile GDI Codul care gestionează tabelul de obiecte GDI se numește handler manager (Handle ManaGeR); acesta este motivul pentru care abrevierea hmgr este atât de comună atunci când se examinează structura internă a GDI Conform overhead-ului lui Fosterer, win k sys menține o variabilă globală numită gpentHmgr care indică începutul tabelului de obiecte GDI în spațiul de adrese kernel Numărul maxim de obiecte GDI pe care le poate deține un tabel de obiecte GDI este de De obicei, tabelul este utilizat doar parțial, așa că multe intrări din tabel sunt lăsate goale Win k sys menține o altă variabilă globală, gcMaxHmgr, care stochează indexul maxim al elementului de tabel afectat GdiTableCell *gpentHmgr; gcMaxHmgr lung nesemnat; Intrarea GDI Object Table este o structură de biți pe care am numit-o GdiTableCell (consultați secțiunea „Descifrarea tabelului de obiecte GDI”) Tipuri de obiecte GDI din motorul GDI Cu toții suntem familiarizați cu obiectele GDI, cum ar fi pixuri, pensule, fonturi, regiuni, palete și așa mai departe Cu toate acestea, există multe alte tipuri de obiecte în tabelul de obiecte GDI care nu se găsesc la nivelul API Win În tabel Figura listează tipurile de obiecte GDI obţinute din comanda dumphmgr Tabelul Tipuri de obiecte GDI Tip Identificator de tip Descriere DEFTYPE x Obiecte GDI la distanță DCTYPE x , x Contextul dispozitivului, metafișier DD DRAW TYPE x Obiect DirectDraw (acum gestionat separat) Suprafața DDSURFTYPE x DirectDraw (acum manipulată separat) TIP RGN x Regiunea Structuri de date în modul kernel Tip ID tip Descriere SURF TYPE x Raster dependent de dispozitiv CLIOBJTYPE x Obiect client PATH TYPE x Cale Paleta PALTYPE x ICMCSTYPE x LFONTJTYPE x a font boolean RFONT TYPE x b PFE TYPE OxOc PFTTYPE OxOd ICMCXFTYPE x e ICMDLLTYPE OxOf PERIE-TIP x , x Perie, stilou D D HANDLE TYPE x DDVPORTTYPE x SPACETYPE x DDMOTIONTYPE x METATIP x EFSTATE TIP x BMFD TYPE x VTFDTYPE x TTFD TYPE x RCTYPE Oxla TEMP TYPEOxlb DRVOB TYPE x c DCIOBJTYPE Oxid SPOOLTYPE Oxle Din cele peste de tipuri de obiecte enumerate în tabel , doar câteva sunt cunoscute de programatorii Win , cum ar fi obiectele DCTYPE, BRUSH TYPE și LFONTTYPE corespunzătoare contextului dispozitivului, pensulă/pen-ului și fontului logic Fapt amuzant: pensulele și pixurile sunt de același tip BRUSHJTYPE, deși identificatorii de tip sunt oarecum diferiți Win API nu conține Capitolul Structuri interne de date GDI/DirectDraw funcții pentru crearea directă a obiectelor de traiectorie (PATH TYPE), deși logica sugerează că un obiect este încă creat în memorie Construcția traiectoriei începe cu un apel la funcția BeginPath Cu ajutorul extensiei de depanare GDI, examinăm structurile de date ale nucleului create pentru obiectele GDL Contextul dispozitivului în motorul GDI Contextul dispozitivului este unul dintre principalele obiecte ale GDL, numeroasele sale atribute definesc diferite aspecte ale modului în care API-ul Win interacționează cu un dispozitiv grafic, fie că este o placă video, imprimantă, plotter sau fototypesetter GDI stochează datele contextului dispozitivului în două locuri Structura modului utilizator DC ATTR conține atribute precum creionul curent, pensula curentă, fundalul și culorile textului Structura DC ATTR este definită în secțiunea „Urmărirea interfețelor COM DirectDraw” din Capitolul Motorul GDI menține și structura DCOBJ în spațiul de adrese al nucleului; această structură conține informații complete despre obiectul context al dispozitivului, inclusiv o copie a DC ATTR Pentru un handle de context de dispozitiv, câmpul pKernel al intrării din tabelul obiect GDI se referă la o instanță DCOBJ, iar câmpul pUser se referă la o instanță DC ATTR Extensia de depanare GDI acceptă mai multe comenzi pentru a decoda structurile de date asociate cu mânerele dispozitivului Comanda ddc decriptează HDC-ul și scoate în principal conținutul DCOBJ; comanda dcl scoate la ieșire conținutul structurii DCLEVEL cu structura DCOBJ; comanda dea imprimă conținutul structurii DC ATTR, care este prezentă atât în spațiul de adrese kernel, cât și în spațiul de adrese utilizator Mai jos este ceea ce știm despre aceste structuri // dcobj h // Windows , typedef struct f ( xlB ) bytes t HPALETTE hpal: void*ppal: void*pColorSpace: nesemnat IcmMode; ISaveDepth nesemnat; nesemnat unkl ; HGDIOBJ hdcSave: nesemnat unk [ ]; void*pbrFill: void*pbrLINE: void*unk ela d : HGDIOBJ hpath; // HPATH f Path nesemnat: // PathFlags LINEATTRS lapath; // x octeți void*prgnCUp; void*prgnMeta; COLORADJUSTMENT ca: // x octeți flFontState nesemnat: Structuri de date în modul kernel nesemnat uf : nesemnat unk [ ] fl nesemnat; flashbrush nesemnat; MATRIX mxWorldToDevice; MATRIX mxDevleeToWorld; FLOATOBJ efMllPtoD; FLOATOBJ efM PtoD; FLOATOBJ efDxPtoD; FLOATOBJ efDyPtoD; FLOATOBJ efMllJWIPS; FLOATOBJ efM TWIPS; FLOATOBJ efPrll; FLOATOBJ efPr ; void *pSurface; DIMENSIUNE dimensiune; }DCLEVEL; // Windows , ( x bytes typedef struct { HGDIOBJ hHmgr; // void *pEntry; // ULONG cExcLock; // ULONG Tld; // c DHPDEV dhpdev; // x dctype nesemnat; fs nesemnat; // Steaguri void*ppdev; void*hsem:// x flGraphlcs nesemnate; flGraph cs nesemnat; pdcattr nesemnat; // Indicator către DC ATTR DCLEVEL dcLevel; // x xlB ( ) octeți DC ATTR dcAttr; // x C ( ) octeți hdcNext nesemnat; // OhZVO hdcPrev nesemnat; RECTL erei Clip; nesemnat unk [ ]; RECTL ereiWindow; RECTL erclBounds; nesemnat unk [ ]; void*prgnAPI; void*prgnVIs; void*prgnRao: PUNCTUL FlllOrlgln; nesemnat unk [ ]; void *pcal; // Indicator către DCLEVEL ca nesemnat unk [ ]; void*pca ; nesemnat unk [ ]; void*pca ; nesemnat unk [ ]; void*pca ; Capitolul Structuri interne de date GDI/DirectDraw nesemnat unka [ ] HFONT hlfntCur; nesemnat unkb [ ]: void*prfnt: nesemnat unkc [ ] nesemnat unkd OOOOffff; nesemnat unke ffffffff: nesemnat unkf [ ]; }DCOBJ: Ultima descriere detaliată a structurilor precum DCOBJ a fost în Schulman, Maxi (Maheu) și Pietrek's Undocumented Windows, publicat în Această carte ne-a ajutat să înțelegem unele dintre câmpurile moștenite de la Windows / , atât decodate, cât și nedecodificate de comenzile extensiei debugger Pentru fiecare obiect GDI, datele în modul kernel încep cu o structură de octeți Primul câmp stochează mânerul GDI al obiectului; al doilea câmp conține un pointer necunoscut; al treilea câmp este numărul de blocări, iar ultimul câmp este ID-ul firului de execuție al programului care a creat obiectul Din mâner, motorul GDI poate căuta tabelul de obiecte GDI și poate determina cărui proces îi aparține mânerul, precum și să acceseze structuri în modul utilizator (cum ar fi DC ATTR) Primul câmp de după antet, dhpdev, conține un handle pentru structura PDEV controlată de driverul dispozitivului grafic Driverul de dispozitiv grafic trebuie să fie capabil să gestioneze mai multe dispozitive fizice Pentru a face acest lucru, driverul de dispozitiv definește structura de date necesară pentru a gestiona aceste dispozitive Documentația Windows DDI se referă la aceste structuri sub numele PDEV; sunt definite și utilizate numai de driverul dispozitivului Pentru ca șoferul să creeze și să inițializeze structura PDEV, motorul GDI apelează funcția DrvEnablePDEV a șoferului Deoarece structura PDEV este gestionată exclusiv de driverul de dispozitiv, mecanismul GDI nu este interesat de detaliile structurii sale, astfel încât DDI (Device Driver Interface) permite DrvEnablePDEV să returneze un handle PDEV în loc de un pointer către un PDEV Mecanismul GDI este corect prin faptul că permite dezvoltatorului driverului să ascundă implementarea în spatele mânerului, similar modului în care motorul GDI însuși își ascunde implementarea în spatele mânerelor GDI Mânerul obținut prin apelarea DrvEnablePDEV este folosit de motorul GDI la apelurile ulterioare către dispozitivul fizic pentru a crea o suprafață grafică Pentru a elibera memoria și resursele ocupate de dispozitivul fizic, motorul GDI apelează funcția DrvDi sabl ePDEV Windows NT/ DDK include exemple de cod sursă pentru mai multe drivere de afișare, toate care utilizează structuri PDEV diferite Funcția DrvEnablePDEV, de regulă, returnează un pointer obișnuit către PDEV ca manipulator După cum știm din API-ul Win , există mai multe tipuri diferite de contexte de dispozitiv În structura DCOBJ, aceste diferențe sunt indicate în câmpul dctype În prezent, există trei tipuri de contexte: typedef enumerare Structuri de date în modul kernel DCTYPE DIRECT = DCTYPE MEM RY = , DCTYPE INF = // contextul dispozitivului normal // context compatibil // context informațional Câmpul fs al structurii DCOBJ conține steaguri legate de contextul dispozitivului Următoarele sunt câteva dintre semnalizatoarele rezultate de extensia GDI typedef enumerare { DC DISPLAY DC DIRECT DC CANCELED DC PERMANENT DC DIRTY RAO DC ACCUM WMGR DC ACCUM APP DC RESET = x = x = x = x = x = x = x = x DC SYNCHRONIZEACCESS = x , DC EPSPRINTINGESCAPE DCJEMPINFODC DC FULLSCREEN DC IN CLONEPDEV DC REDIRECTION = x = x = x = x = x }DCFLAGS; Următorul câmp DCOBJ este scos de extensia GDI sub numele ppdev Este destul de firesc să presupunem că această abreviere înseamnă „Pointer to Physical Device”, adică „pointer către un dispozitiv fizic” Extensia GDI oferă chiar și o comandă dpdev pentru a decoda un pointer către PDEV Dar, conform DDK, structura de date a dispozitivului fizic este sub controlul driverului de dispozitiv, iar motorul GDI nu ar trebui să știe nimic despre asta Funcția driver DrvEnablePDEV returnează un handle de dispozitiv fizic în loc de un pointer către acesta O posibilă explicație este că motorul GDI își creează propria structură de date pentru dispozitivul fizic, pe care îl vom numi PDEV WIN K pentru a evita confuzia cu structura PDEV a șoferului Structura PDEV WIN K este extrem de complexă O vom arunca o privire mai atentă în subsecțiunea următoare Câmpul hsem se referă la o structură de semafor Evident, semaforul este conceput pentru a sincroniza accesele pe câmp Câmpurile flGraphics și flGraphics stochează indicatoarele de capacitate a dispozitivului Compoziția acestor steaguri este documentată în DDK; acestea includ steaguri GCAPS ALTERNATEFILL, GCAPS WINDINGFILL, GCAPS COLOR DITHER și așa mai departe Flag-urile f Graphics și flGraphics sunt preluate din structura DEVINFO completată cu funcția DrvEnablePDEV a driverului de dispozitiv Câmpul pdcattr se referă la structura DC ATTR a acestui context de dispozitiv în spațiul de adrese în modul utilizator, care conține majoritatea atributelor contextului Structura DCOBJ conține o copie a acestei structuri în câmpul dcAttr Poate că designerii GDI au dorit să optimizeze procesul de atribuire a valorilor atributelor DC prin minimizarea utilizării codului în mod kernel; pentru a face acest lucru, structura DC ATTR trebuie să se afle în spațiul de adrese în modul utilizator Cu toate acestea, dezvoltatorii au vrut să simplifice dosarul Capitolul Structuri interne de date GDI/DirectDraw este stupid la atributele în modul kernel, pentru care o copie a DC ATTR trebuie să fie și în modul kernel Sincronizarea a două copii ale DC ATTR se realizează folosind steaguri speciale În procesul de analiză a structurii DC ATTR, s-a dovedit că efectuarea unor funcții cu mânerul contextului dispozitivului (de exemplu, selectarea HVITMAP într-un context de dispozitiv compatibil sau selectarea unei palete într-un DC) nu afectează conținutul tabelului de obiecte in orice fel În cazul în care vă întrebați, aceste atribute sunt stocate în structura DCLEVEL conținută în DCOBJ Structura DCLEVEL conține informații despre paletă, adâncimea culorii, ajustarea culorii, atributele liniei, regiunea de tăiere, transformări, trasee și așa mai departe Structura PDEV în motorul GDI Toate driverele grafice acceptă punctul de intrare DrvEnableDriver de bază Când driverul este încărcat, motorul GDI apelează funcția DrvEnableDriver, care populează structura DRVENABLEDATA DrvEnableDriver oferă motorului GDI un tabel de funcții implementate, indicându-i astfel care funcții sunt acceptate de driver DirectDraw creează, de asemenea, câteva tabele cu funcții de apel indirect Desigur, motorul GDI trebuie să stocheze informațiile primite specifice șoferului într-o structură de date Următoarea este o descriere a structurii PDEV a mecanismului GDI // Windows ( xCE ) byte typedef struct { antet nesemnat[ ]; vold*ppdevNext; // int cPdevRefs:// int cPdevOpenRefs:// vold*ppdevParent:// c steaguri nesemnate; // nesemnat flAccelerated:// void*hsemDevLock; // void * hsemPointer: // c PUNCT ptlPointer:// nesemnat unk [ ]; // SPRITESTATE SpriteState; // (ldc) octeți HFONT hlfntDefault:// c HFONT hlfntAnsiVariable: // HFONT hlfntAnsiFixed; // HGDIOBJ ahsurf[ ]; // nesemnat unk [ ]; // void*prfntActive:// void* prfntlnactive:// c nesemnat clnactive:// nesemnat unk [ ]; // void * pfnDrvSetPointShape; // c void *pfnDrvMovePointer; // c void * pfnMovePointer: // c void*pfnSync; // cc Structuri de date în modul kernel nesemnat unk d ; // d void * pfnDrvSetPalette; // d nesemnat unk d [ ]; // d void*pldev; // e DHPDEV dhpdev; // e void *ppalSurf:// e DEVINFO devinfo; // ec- GDIINFO gdiinfo; // - void *pSurface; // void * hSpooler; // c pDesktopId nesemnat; // nesemnat unk ; // EDD DIRECTDRAW GLOBAI eDirectDrawGlobal: // ( x ) octeți void*pGraphicsDevice:// b POINT ptlOrigine; // b c DEVMODEW*pdevmode; // b nesemnat unk b [ ]; // b void *apfn[ ]; // b } PDEV WIN K; Structura PDEV WIN K este destul de mare ( octeți) și conține o mulțime de informații legate de driverul de dispozitiv PDEV WIN K este utilizat în principal de motorul GDI atunci când apelează driverul dispozitivului grafic pentru a efectua diverse solicitări ale utilizatorului Structura începe cu un antet necunoscut de octeți Diferitele structuri PDEV WIN K care există în sistem sunt combinate într-un arbore ierarhic Câmpul ppdevNext conține o referință la următoarea structură, iar câmpul ppdevParent indică structura părinte Extensia de depanare GDI acceptă comanda dpdev pentru a decoda structura PDEV WIN K Această comandă are o opțiune -R pentru a lista recursiv toate structurile la care face referire structura părinte Dacă utilizați opțiunea -R pe o structură PDEV WIN K corespunzătoare unui context de afișare a dispozitivului, veți vedea că câmpul ppdevNext este asociat cu structurile PDEV WIN K ale mai multor drivere de font Există mai multe tipuri de drivere grafice în Windows GDI, fiecare cu caracteristici specifice Șoferii sunt clasificați în funcție de steaguri de câmp În tabel listează unele dintre steagurile acceptate de extensia GDI Tabelul Indicatori ale structurii PDEV WIN K Interpretarea steagului PDEV DISPLAY Ieșire ecran PDEV HARDWARE POINTER Suport hardware pentru cursor PDEV GOTFONTS Prezența unui driver de font PDEV DRIVER PUNTED CALL Șoferul returnează cereri către motorul GDI PDEV FONTDRIVER Driver de font Capitolul Structuri interne de date GDI/DirectDraw Următoarele câteva câmpuri sunt pentru controlul cursorului mouse-ului în driverele de afișare Câmpul hsemPointer este un semafor care sincronizează operațiile cu cursorul mouse-ului Driverul de dispozitiv oferă mai multe funcții de apel indirect pentru afișarea cursorului mouse-ului; adresele acestor funcții sunt stocate în câmpurile pfnDrvSetPointerShape și pfnDrvMovePointer Pe sistemul autorului, aceste câmpuri se referă la mga !DrvSetPointerShape și mga !DrvMovePointer Structurile SPRITESTATE și DIRECTDRAWGLOBAL implementate în PDEVWIN K se referă la implementarea DirectDraw Ne vom uita la aceste structuri în secțiunea următoare PDEVWIN K stochează manipulatoare pentru trei fonturi În sistemul autorului, câmpul hlfntDefault se referă la tipul „System”, câmpul hlfntAnsiVariable se referă la tipul „MS Sans Șerif”, iar câmpul hlfntAnsiFixed se referă la tipul „Connger” Deși Windows GDI încearcă să urmeze principiul WYSIWYG, există probleme cu periile de contur În GDI, o perie cu dungi este definită ca un bitmap monocrom de x Pe ecranele între dpi și dpi, modelele orizontale, verticale, diagonale sau trellis arată destul de normal Cu toate acestea, la imprimantele cu rezoluții de la la dpi și chiar mai mari, modelul rasterelor definit de matrice de x pixeli se transformă în ondulații gri solide Pentru a face periile de contur mai vizibile pe dispozitivele de înaltă rezoluție, mecanismul GDI permite driverului de dispozitiv să treacă propriile hărți de biți pentru a implementa cele șase tipuri standard de perii de contur Windows GDI Funcția EnablePDEV a driverului de dispozitiv poate trece o matrice de șase pointeri de suprafață (rastere), iar mânerele obiectelor GDI corespunzătoare sunt stocate în matricea ahsurf În timp ce driverele de ecran sunt încurajate să treacă aceste mânere, structura PDEV a ecranului WIN K DC include șase mânere raster standard x transmise implicit de GDI Structurile GDI există de obicei în perechi; o structură se referă la descrierea logică, iar cealaltă la implementarea fizică Prin urmare, pentru structura dispozitivului fizic PDEV WIN K, ar trebui să căutați o structură asociată cu o descriere logică Un pointer către o astfel de structură este stocat în câmpul pldev, iar structura în sine este decodificată de comanda extensiei dldev GDI Structurile LDEV WIN K formează o listă dublu legată Începând cu contextul ecranului dispozitivului, lista este deschisă de un driver de ecran (de exemplu, „\SystemRoot \System \mga dll”), urmat de mai multe drivere de font Secvența este încheiată de driverul de font ATM ("\SystemRoot\System \atmfd dll") // Windows , ( x ) octeți typedef struct { LDEV WIN K *nextldev; LDEV WIN K *prevldev; ULONG evtype; ULONG cRefs: ULONG unk ; void *pGdiFriverInfo; ULONG ulDriverVersion; PFN apfn[ ]; }LDEV WIN K; Structuri de date în modul kernel Conform protocolului generat de Fosterer, extensia de depanare GDI citește valoarea variabilei globale win k!gpldevDrivers pentru a obține prima structură logică a dispozitivului grafic Structura PDEVWIN K conține o copie a structurii DEVINFO populată de punctul de intrare DrvEnablePDEV al driverului grafic Structura DEVINFO este documentată în DDK Practic, descrie capacitățile driverului de dispozitiv pentru gestionarea curbelor, fonturilor, formatelor grafice, lucrul cu culoarea etc Structura PDEV WIN K conține, de asemenea, o copie a structurii GDIINFO, populată și de punctul de intrare DrvEnablePDEV și documentată în DDK Structura GDIINFO conține practic informații despre dimensiunea, formatul și rezoluția suprafeței grafice Multe câmpuri ale structurii GDIINFO pot fi preluate folosind funcția API GetDeviceCaps Win De exemplu, apelul GetDeviceCaps(hDC, TECHNOLOGY) este legat de câmpul ulTechnology al structurii GDIINFO, iar valoarea GetDeviceCaps(hDC, RASTER-CAPS) este preluată din câmpul flRaster al structurii GDIINFO Câmpul pSurface se referă la structura suprafeței SURFACE în care sunt efectuate efectiv toate operațiunile grafice Structura suprafeței este discutată mai târziu în această secțiune Câmpul pdevmode se referă la structura DEVMODEW, versiunea Unicode a DEVMODE Structura DEVMODE este de obicei inițializată de driverul grafic și modificată de aplicația utilizator, ceea ce permite nu numai primirea de informații de la driverul dispozitivului, ci și modificarea valorilor parametrilor care sunt permise de driver Structura DEVMODE nu este deosebit de utilă pentru ieșirea pe ecran, dar driverul de imprimantă obține informații importante despre calitatea imprimării, dimensiunea hârtiei, tipul suportului, rezoluția și așa mai departe Ultimul și cel mai important câmp al structurii PDEV WIN K, apfn, este un tabel cu de indicatori de funcție În Windows , interfața DDI definește de funcții care pot fi implementate de un driver de dispozitiv grafic; fiecărei funcţii îi corespunde un index prestabilit De exemplu, indexul INDEX DrvEnable ePDEV este , iar indexul INDEX DrvSynchronizeSurface este Unii dintre acești de indici nu sunt utilizați, alții sunt rezervați, alții sunt doar pentru drivere de afișare, iar altele sunt doar pentru driverele de imprimantă Doar o mică parte din aceste funcții trebuie neapărat implementate de driverele de dispozitiv; restul functiilor sunt optionale Când este încărcat un driver de dispozitiv, sistemul apelează funcția DrvEnableDriver, care populează structura DRVENABLEDATA Practic, structura DRVENABLEDATA este un tabel comprimat cu de indicatori de funcție Atribuirea de valori la de indicatori de funcție este plictisitoare, predispusă la erori și puțin extensibilă Din acest motiv, motorul GDI permite șoferului să treacă o listă de funcții pe care le suportă, împreună cu indici, pe baza cărora motorul GDI construiește tabelul extins Tabelul de funcții este stocat în două locuri Structura logică a dispozitivului LDEV WIN K conține tabelul de funcții inițial construit din datele DRVENABLEDATA și primit de la driverul dispozitivului Structura dispozitivului fizic PDEV WIN K conține tabelul utilizat efectiv de motorul GDI; acest tabel conține funcții din WIN K LDEV, precum și puncte de intrare ale motorului GDI pentru implementarea funcțiilor care nu sunt acceptate de driverul de dispozitiv De exemplu, dacă un driver de dispozitiv nu acceptă DrvBitBlt, de fapt apelează motorul GDI cu Capitolul Structuri interne de date GDI/DirectDraw solicitarea de a furniza o implementare a acestei funcții Din acest motiv, tabelul de funcții PDEV WIN K în loc de un pointer NULL conține un pointer către funcția win k sys - wi n ! SpBi tBl t În tabel prezintă conținutul tabelului de funcții DDI de pe computerul autorului Tabelul Exemplu de tabel de funcții PDEV WIN K Adresă index Nume funcție fdd f mga !DrvEnablePDEV fdd mga !DrvCompletePDEV fdd mga !DrvDi sablePDEV fdd b mga !DrvEnableSurface fdd mga !DrvDi sablePDEV fdd mga !DrvAssertMode fdd mga !Drv ffset fdd fa mga !DrvResetPDEV fdd fc mga !DrvCreateDeviceBi tmap Și fdd fd mga !DrvDeleteDeviceBi tmap fdd fb mga !DrvReal i zeBrush fdd cc mga !DrvDitherColor a a fe wi n k!SpStrokePath ' aOOaaafc win k!SpFi Path fdd mga !DrvPaint aOO b win k!SpBitBlt a d d win k!SpCopyBits a win k!SpStretchBlt fdd cl mga !DrvSetPalette a d e win k!SpText ut fdd fcc mga !DrvEscape fdd del mga !DevSetPointShape fdd df mga !DrvMovePointer aooaab win k!SpLineTo a c wi n k!SpSaveScreenBlt Structuri de date în modul kernel Adresă index Nume funcție fdd mga !DrvGetModes fdd bf mga !DrvDestroyFont fdd efl mga !DrvGetDi rectDrawInfo fdd fl mga !DrvEnableDi rectDraw fdda mga !DrvDi sableDirectDraw fdd dc mga !DrvIcmSetDeviceGammRamp a wi n k!SpGradientFi a wi n k!SpStretchBltROP a dl win k!SpPlgBlt aOlOdOfl wi n k!SpALphaBlend a d wi n k!SpTransparentBlt După cum se poate observa din tabel, în cazul driverului de ecran, motorul GDI realizează activitatea principală de afișare a curbelor, umplerilor, textului și hărților de biți, în timp ce driverul de ecran efectuează inițializarea, operațiile cu cursorul mouse-ului, implementarea obiectelor etc Suprafețe în motorul GDI La nivelul motorului GDI, funcțiile grafice operează pe suprafețele asociate driverului de dispozitiv pe care se realizează ieșirea Când lucrați cu suprafețele dispozitivelor, este utilizat un sistem de coordonate care seamănă cu modul de afișare API MM TEXT GDI Pixelii de suprafață sunt adresați ca perechi de numere întregi semnate pe de biți; originea coordonatelor este situată în colțul din stânga sus - punctul ( , ) Suprafața dispozitivului se află în cadranul din dreapta jos al acestui sistem de coordonate, iar ambele coordonate iau doar valori nenegative Deși coordonatele sunt stocate și transmise în API-ul Win ca numere întregi semnate pe de biți, în unele operațiuni grafice motorul GDI folosește cei biți inferiori ai întregului pe de biți pentru a reprezenta coordonate suplimentare (subpixeli) care măresc acuratețea calculelor Motorul GDI definește două tipuri principale de suprafețe Suprafețele de primul tip, controlate de mecanismul GDI, sunt de obicei menționate în documentația DDK ca bitmap-uri independente de dispozitiv (DIB) Suprafețele conduse de GDI constau dintr-un singur plan de culoare cu pixeli împachetati și alinierea liniei de scanare pe granițele de cuvinte duble Dacă un driver de dispozitiv funcționează cu o suprafață controlată de motorul grafic, toate ieșirile de pe acea suprafață pot fi realizate folosind GDI Suportul din partea motorului GDI în drivere de ecran simple sau drivere de imprimantă raster simplifică foarte mult driverele în sine Capitolul Structuri interne de date GDI/DirectDraw și însoțirea lor Driverul framebuffer de probă inclus cu Windows DDK creează o suprafață condusă de motorul grafic ca suprafață de bază și commite ieșirea GDL la ieșire Driverul de imprimantă Windows UniDrv utilizează, de asemenea, suprafețe bazate pe grafică după împărțirea paginii fizice într-o serie de dreptunghiulare benzi Al doilea tip include suprafețele controlate de dispozitiv; adică driverelor de dispozitive li se permite să-și gestioneze propriile suprafețe În reprezentarea internă, formatul suprafeței controlate de dispozitiv poate fi același cu formatul suprafeței controlate de motorul grafic sau diferit de acesta Dacă formatele se potrivesc, driverul dispozitivului poate efectua operațiuni grafice folosind GDI Bitmapurile în format dispozitiv sunt o categorie specială de formate specializate de suprafață bazate pe dispozitiv Această caracteristică este acceptată, astfel încât unele drivere de afișare să poată implementa copierea accelerată a bitmap-urilor pe ecran De asemenea, le permite driverelor să iasă în memoria video stocată sau să lucreze cu hărți de bit în formate non-standard Structura principală de date pentru reprezentarea diferitelor suprafețe GDI este structura SURFOBJ Structura SURFOBJ este documentată în Windows NT/ DDK Ocupă unul dintre locurile centrale în interfața DDI și este folosit pentru a reprezenta atât hărți de bit, cât și suprafețe grafice Deoarece structura SURFOBJ este foarte importantă pentru funcționarea mecanismului GDI, definiția de mai jos este preluată din documentația DDK typedef struct SURFOBJ { DHSURF dhsurf; HSURF hsurf; DHPDEV dhpdev; HDEV HDEV: SIZEL sizlBitmap; ULONG cjBits; PVOID pvBits; PVOID pvScanO: LONG Delta; ULONG Uniq; ULONG IBitmapFormat; USHORT iType; USHORT fjBitmap; }SURFOBJ; Primul câmp, dhsurf, stochează un mâner care este folosit pentru a identifica suprafețele controlate de dispozitiv; poate fi un pointer, un index sau orice altă valoare cu care poate lucra driverul de dispozitiv Câmpul hsurf conține mânerul GDI pentru suprafață, de obicei un raster specific dispozitivului sau mânerul secțiunii DIB Câmpul dhpdev conține mânerul de structură PDEV al driverului de dispozitiv returnat de funcția DrvEnablePDEV Câmpul hdev stochează mânerul logic GDI pentru dispozitivul fizic Structuri de date în modul kernel Dimensiunea pixelilor suprafeței este determinată de câmpul sizl Bi tmap al structurii SURFOBJ Pentru suprafețele gestionate de motorul GDI, câmpul pvBits indică datele grafice ale rasterului de suprafață; câmpul cjBits specifică dimensiunea acestuia, iar câmpul pvScanO indică către prima linie de scanare a rasterului Rețineți că suprafețele DIB pot fi stocate cu susul în jos sau cu susul în jos în memorie În acest din urmă caz, pvBits nu se potrivește cu pvScanO Câmpul Delta stochează offset-ul liniilor de scanare adiacente în octeți; cu această valoare, motorul GDI se poate deplasa rapid între liniile de scanare Pentru rasterele normale, valoarea câmpului Delta este pozitivă, iar pentru rasterele inversate, este negativă Câmpul Uniq este pentru optimizare Conține starea curentă a suprafeței controlată de motorul grafic și este actualizată ori de câte ori suprafața se schimbă Acest lucru permite driverului dispozitivului să organizeze stocarea în cache de suprafață De exemplu, dacă un driver de imprimantă PostScript primește două solicitări de redare a unui raster cu același raster sursă și aceleași valori iUniq, driverul trebuie doar să stocheze rasterul original atunci când procesează prima solicitare și să îl folosească atunci când primește a doua cerere Câmpul iBitmapFormat al structurii SURFOBJ specifică formatul standard de suprafață controlat de motorul grafic care se potrivește cel mai bine cu formatul suprafeței date Aceasta poate fi o imagine cu , , , , și de biți pe pixel, necomprimată sau comprimată de algoritmul RLE În Windows , driverul de dispozitiv GDI poate suporta și imagini JPEG și PNG comprimate prin setarea câmpului IBitmapFormat la BMF JPEG și, respectiv, BMF PNG Cu toate acestea, nici Windows GDI, nici motorul grafic nu acceptă lucrul cu imagini JPEG sau PNG; aceste imagini sunt pur și simplu transmise driverului de dispozitiv dacă acesta din urmă pretinde că acceptă aceste formate Câmpul iType specifică tipul suprafeței Valorile permise sunt listate în tabel Tabelul Tipuri de suprafață SURFOBJ iTour Descriere STYPE-BITMAP STYPEDEVICE STYPE-DEVBITMAP Raster condus de GDI Suprafață condusă de șofer Raster condus de șofer în format dispozitiv Ultimul câmp, fjBitmap, conține niște steaguri pentru suprafețele controlate de motorul grafic Aceste steaguri indică dacă rasterul este stocat vertical sau invers, inițializat la zero, tranzitiv sau nu în memoria sistemului Dacă structura SURFOBJ ar trebui să reprezinte toate suprafețele grafice ale motorului GDI, unde sunt stocate informațiile de culoare, cum ar fi paleta? În motorul GDI, managementul culorilor este separat de SURFOBJ Pentru fiecare apel grafic folosind SURFOBJ, este transmis un pointer către o structură Capitolul Structuri interne de date GDI/DirectDraw turul XLATE BJ, care oferă conversie de culoare între suprafețele sursă și țintă, dacă este necesar De exemplu, funcțiile DrvStretchBlt și DrvPlgBlt folosesc un parametru pxio care conține un pointer către un obiect XLATEOBJ Rastere dependente de dispozitiv în motorul GDI Bitmapurile dependente de dispozitiv (DDB) sunt gestionate de driverele de dispozitive grafice activate pentru Windows GDL Înainte ca o suprafață DDB să poată fi utilizată, trebuie creat un obiect GDI pentru aceasta și este returnat un handle de tip HBITMAP Deși se așteaptă ca bitmapurile specifice dispozitivului să fie suportate nativ de driverul de dispozitiv, un număr tot mai mare de drivere de dispozitiv Windows NT/ externalizează majoritatea operațiunilor grafice către motorul GDI Pentru a face acest lucru, formatul rasterelor lor trebuie să se potrivească cu formatul acceptat de motorul GDL HBITMAP se află, de asemenea, sub controlul managerului de mâner GDL De aceea, fiecare mâner din tabelul de obiecte GDI are octeți de informații asociați, inclusiv un pointer către o structură din spațiul de adrese al nucleului În extensia de depanare GDI, această structură se numește SURFACE Partea principală a structurii SURFACE este structura SURFOBJ Definiția unei structuri SURFACE arată astfel: // Windows , ( x ) octeți typedef struct { HGDIOBJ hHmgr; // void*pEntry:// ULONG cExcLock; // ULONG Tid: // c SURFOBJ surfobj:// , documentat în DDK XDCOBJ * pdcoAA:// , produs de gdikdx Steaguri FLONG: // palette ppal:// c nesemnat unk [ ]; // SIZEL sizl Dim[ ]; // hdc hdc:// ULONG cRef: // HPALETTE hpalHint:// nesemnat unk c[ ]; // c } SUPRAFATA: Structura SURFACE, ca și structurile de bază ale altor obiecte GDI, începe cu un antet de octeți Antetul este urmat de o structură SURFOBJ cu informații despre format, dimensiune, date grafice și așa mai departe Structura SURFACE trebuie să descrie complet bitmap-ul GDI, fie o secțiune DDB, fie o secțiune DIB Prin urmare, structura SURFACE după structura SURFOBJ stochează mânerul paletei și un pointer către structura PALETTE PALETTE este o structură în mod kernel pentru obiectul paletă logică GDI Ne vom uita la structura PALETTE într-o secțiune ulterioară a acestui capitol Structuri de date în modul kernel Câmpul de steaguri din structura SURFACE conține steaguri BITMAP API (hartă de biți generată de API Win ) și DDB SURFACE (hartă de biți specifică dispozitivului API Win ) Rasterele API Win specifice dispozitivului și secțiunile DIB pot fi selectate în contextul dispozitivului În acest caz, câmpul hdc conține mânerul de context al dispozitivului, iar câmpul cRef conține numărul de alegeri de obiect în DC Câmpul si zl Dim oferă suport pentru funcțiile API Win SetBitmapDimensionEx și GetBitmap-DimensionEx, oferind un loc pentru stocarea dimensiunilor fizice ale unui bitmap Terminologia Win GDI API și Windows NT/ DDK este adesea confuză; în ambele cazuri se folosesc termenii DIB și DDB Există trei tipuri de rastere în API-ul Win : rastere dependente de dispozitiv (DDB), secțiuni DIB și rastere independente de dispozitiv (DIB) Suprafețele DDB și secțiunile DIB sunt gestionate de GDI; aceasta înseamnă că operațiunile de creare, selectare, copiere a datelor, scriere a datelor și distrugere finală a acestora trebuie efectuate prin intermediul API-ului GDI Cu toate acestea, DIB-urile nu sunt de competența GDI Puteți crea singur un DIB fără ajutorul GDI Citirea și scrierea datelor grafice se realizează direct de către pointer, fără utilizarea unui manipulator și GDI GDI oferă mai multe funcții pentru ieșirea DIB în contexte de dispozitiv GDI La nivelul motorului GDI, toate rasterele Win — secțiunile DDB, DIB și DIB — sunt suprafețe Evident, secțiunile DIB și DIB se referă la suprafețe gestionate de mecanismul GDI (în documentația DDK sunt combinate prin termenul DIB) Cu toate acestea, DDB-urile pot fi stocate atât în format DIB, cât și în format de dispozitiv (DDB în documentația DDK) - totul depinde de driverul dispozitivului grafic Fiecare raster dependent de dispozitiv (DDB) corespunde unui manipulator GDI (HBITMAP) Informațiile complete despre un raster sunt stocate în structura SURFACE a spațiului de adrese kernel Pentru driverele de ecran tipice, câmpul iType al unei structuri SURFOBJ dintr-o SURFACE este de obicei egal cu STYPE BITMAP; câmpul f jBitmap este de obicei BMF TOPDOWN; câmpul steagurilor este de obicei egal cu API BITMAP | DDB SURFACE și câmpul pvBits indică spațiul de adrese kernel Astfel, memoria pentru datele grafice DDB este alocată în spațiul de adrese kernel partajat din pool-ul paginat Secțiuni DIB în motorul GDI În terminologia Win API, o secțiune DIB este un bitmap care este gestionat de GDI, dar este disponibil pentru programele utilizatorului direct printr-un pointer Secțiunile DIB sunt create de funcția CreateDIB-Section, trecând descrierea în structura BITMAPINFO GDI returnează un mâner HBITMAP care poate fi manipulat în același mod ca mânerele DDB, precum și un pointer către date grafice care pot fi citite și scrise prin indicator ca și conținutul unui bloc normal de memorie Într-un tabel de obiecte GDI, o secțiune DIB este aproape echivalentă cu un DDB Are, de asemenea, un manipulator și o structură SURFACE în spațiul de adrese al nucleului Principala diferență este că memoria pentru datele grafice ale secțiunii DIB este alocată în spațiul de adrese în modul utilizator în loc de Capitolul Structuri interne de date GDI/DirectDraw spațiu de adrese în modul kernel Datorită acestei circumstanțe, datele grafice devin disponibile pentru programele utilizatorului; în plus, ieșirea GDI poate apărea numai dacă procesul proprietar este procesul curent Câmpul fjBitmap al structurii SURFOBJ pentru secțiunile DIB este BMF DONTCACHE Aceasta înseamnă că driverul grafic nu ar trebui să memoreze în cache datele grafice bazate pe conținutul câmpului i Uni q, deoarece datele grafice pot fi modificate de un program de utilizator fără cunoștințele GDI prin indicatorul obținut prin apelarea Create-DIBSection O altă diferență minoră este că DIB-urile, ca și DIB-urile, sunt de obicei stocate cu capul în jos în memorie, cu excepția cazului în care înălțimea lor primește o valoare negativă Știm că rasterele independente de dispozitiv (DIB) nu sunt gestionate de GDI În special, nu puteți crea handle GDI pentru ele Cu toate acestea, când se transmite un DIB unui driver de dispozitiv, interfața DDI folosește în continuare aceeași structură SURFOBJ în loc de structura BITMAPINFO folosită pentru a reprezenta DIB-ul în API-ul Win Aparent, motorul GDI creează o structură SURFOBJ temporară pentru a reprezenta DIB-ul înainte de a accesa punctele de intrare ale motorului GDI sau driver-ului de dispozitiv Perii în motorul GDI Periile stabilesc culoarea și modelul umplerii unei zone Instrumentele Win API vă permit să creați pensule solide, pensule hașurate, pensule cu model DDB și perii cu model DIB Din secțiunea Structuri de date în modul utilizator, știm că pentru pensulele uniforme se creează o structură mică în spațiul de adrese din modul utilizator pentru a stoca culoarea pensulei, ceea ce îmbunătățește eficiența utilizării pensulelor uniforme Pentru toate celelalte tipuri de pensule, GDI stochează toate informațiile în structura BRUSH a nucleului typedef struct { AttrFlags nesemnate; COLORREF IbColor; } BRUSHHATTR; // Windows , ( x ) octeți (?) typedef struct { HGDIOBJ void * ULONG ULONG hHmgr; pentry; cExcLock: Tld: // , antetul obiectelor GDI în modul kernel // // // c ULONG ulStyle; // HBITMAP hbmPattern:// MÂNER hbmCHent; // ULONG flatAttrs; // c ULONG ulBrushUnlque:// BRUSHATTR*pbrushhttr; // Structuri de date în modul kernel BRUSHATTR*pbrushattr; // nesemnat unk ; // nesemnat bCacheGrabbed:// COLORREF crBack; // COLORREF crFore:// c ULONG ulPal Time: // ULONG ulSurfTime; // ULONG ulRealization; // nesemnat unk c[ ]; // c ULONG ulPenWidth:// nesemnat unk c:// c ULONG ulPenStyle:// DWORD *pStyle; // ULONG dwStyleCount; // nesemnat unk c: } PERIE: Structura BRUSH începe cu un antet standard al obiectului GDI al nucleului de octeți Este urmat de câmpul ulStyle al stilului pensulei, care are o valoare diferită de câmpul corespunzător al structurii LOGBRUSH În extensia de depanare GDI, aceasta este codificată cu constantele HSCROSS, HS PAT, HS DITHEREDCLR și așa mai departe Câmpurile cgBask și crFore stochează culorile de prim plan și de fundal ale contextului dispozitivului, în timp ce câmpul brushAttr lbColor stochează culoarea reală a periei Câmpul flAttrs stochează steaguri suplimentare (Tabelul ) Tabelul Atributele Brush în structura BRUSH BRUSH flAttrs Descriere BR NEED BK CLR ( x ) Este necesară culoarea de fundal BR DITHER OK ( x ) Permite amestecarea culorilor BR IS SOLID ( x ) Perie uniformă BR IS HATCH ( x ) Perie de cursă BR IS BITMAP ( x ) Perie de model DDB BRJSJHB ( x ) DIB Pattern Brush BR IS NULL ( x ) Penie goală BR IS GLOBAL ( x ) Obiecte standard BR IS PEN ( x ) Pen BR IS OLDSTYLEPEN ( x ) Pen geometric BR IS MASKING ( x ) BR CACHED IS SOLIO ( x ) Hartă de biți model utilizată ca mască de transparență Când lucrați cu pensule de model DIB, motorul GDI creează un obiect pentru rasterul pensulei al cărui mâner este stocat în câmpul hbmPattern, în timp ce se află în câmp Capitolul Structuri interne de date GDI/DirectDraw hbmClient rămâne cu mânerul HGLOBAL transmis la apelarea CreateOIB-PatternBrush Pentru periile de model DDB, motorul GDI copiază suprafața DDB originală, stochând mânerul de copiere în câmpul hbmPattern și mânerul de suprafață original în câmpul hbmClient Copierea bitmap-ului original permite programatorului să o ștergă după crearea obiectului pensulă Un obiect tip pensulă nu există niciodată singur; un obiect raster cu model asociat este întotdeauna creat pentru acesta Până acum, ar trebui să aveți o înțelegere destul de bună a modului în care diferitele tipuri de perii sunt reprezentate în motorul GDI Pixuri în motorul GDI Stiloul determină culoarea și stilul liniilor, arcelor și curbelor API-ul Win vă permite să creați pixuri cosmetice și geometrice cu diferite stiluri, grosimi și atribute În mod ciudat, motorul GDI nu definește o structură de date specială pentru reprezentarea pixurilor - folosesc aceeași structură BRUSH ca și pentru pensule Cu toate acestea, pare destul de logic dacă observați că pixurile extinse create de funcția ExtCreatePen sunt definite folosind structura LOGBRRUSH Motorul GDI distinge între pixuri și pensule prin marcajul BR IS PEN din câmpul flAttrs Un alt indicator, BR IS OLDSTYLEPEN, indică dacă stiloul a fost creat utilizând funcția „de modă veche” CreatePen (sau CreatePenIndirect) în loc de „noua” funcție ExtCreatePen Câmpurile ulPenWidth, ulPenStyle, pStyle și dwStyl eCount au aceeași semnificație ca și câmpurile corespunzătoare ale structurii EXTLOGPEN definite în API-ul Win Există o comandă dpbrush în extensia de depanare GDI pentru a descifra structura BRUSH, dar această comandă funcționează numai pe câmpurile legate de perii „reale” Pentru stilourile create cu funcția ExtCreatePen, această comandă returnează informații incomplete Palete în motorul GDI O paletă este un tabel de culori în care indicii de culoare sunt convertiți în valori RGB sau invers, valorile RGB sunt convertite în indicele de culoare original Pentru a lucra cu o paletă într-un context de dispozitiv, trebuie să creați o paletă logică utilizând funcția CreatePalette sau CreateHalf-tonePalette Aceste funcții returnează un mâner de paletă logic (de tip HPALETTE) Pe lângă palete, descrise de obicei de structura LOGPALETTE, Win folosește o altă formă de tabele de conversie a culorilor, structura BITMAPINFO, care face parte din secțiunile DIB și DIB Numărul de indici din tabelul de culori este calculat din informațiile din câmpul bmiHeader al structurii BITMAPINFO, iar datele din tabel în sine sunt stocate în matricea bmiColors Structura BITMAPINFO vă permite să specificați o culoare după index pentru hărțile de biți care conțin până la de culori Atunci când lucrați cu rastere DIB de , și de biți, este, de asemenea, posibil să definiți măști pentru a extrage componentele roșii, verzi și albastre din datele de culoare pe , și de biți Structuri de date în modul kernel Motorul GDI trebuie să accepte o singură implementare pentru ambele traduceri de culoare Sarcina este rezolvată folosind structura EPALOBJ (numele structurii este împrumutat de la gdikdx dll) typedef unsigned long HDEVPPPAL; typedef void * typedef void * typedef unsigne PTRANSLATE; PRGB XL; ?d PAL ULONG; // Windows + n bytes typedef struct EPALOBJ { HGDIOBJ hHmgr: // OOO antetul obiectelor GDI în modul kernel void* pentry; // ULONG cExcLock; // ULONG Tid; // c FLONG flPal; // Centuri ULONG; // ULONG ulTime; // HDC hdcHead; // c HDEVPPPAL hSelectat; // ULONG cRefhpal; // ULONG cRefRegular; // PTRANSLATE ptransFore; // c PTRANSLATE ptransCurrent; // PTRANSLATE ptransOld; // nesemnat unk ; // pGetNearer; // c pGetMatch; // ULONG ulRGBTime; // PRGB XL pRGBClate; // JPALOBJ*pPalette; // c, asta PAL-ULONG*papalColor; // , asta->apa!Color PAL-ULONG apalColorEl]; // }EPALOBJ; Structura EPALOBJ reprezintă un obiect paletă logic în modul kernel, așa că, la fel ca toate structurile obiect GDI, începe cu un antet standard Tipul tabelului de translație a culorilor este determinat de conținutul câmpului flPal În tabel Figura - prezintă valorile obținute din rezultatul extensiei de depanare GDI și parțial din fișierul antet winddi h Tabelul Steaguri EPALOBJ EPALOBJ fIPal Valoare Descriere PALINDEXED x Paletă indexată PAL BITFIELDS x Sunt utilizate măști de biți PAL RGB x Roșu, verde, albastru PAL BGR x Albastru, verde, roșu Continuare Capitolul Structuri interne de date GDI/DirectDraw Tabelul Continuare EPALOBJ fIPal Valoare Descriere PALCMYK x Cyan, magenta, galben, negru PALDC x PALFIXED x Nu poate fi schimbat PAL FREE x PALMONOCROM x Doar două culori PAL DIBSECTION x Folosit pentru secțiunea DIB PALHT x Paletă semiton PAL PGB x Culoare RGB pe biți în format PAL RGB x Culoare RGB pe biți în format Câmpul cEntries stochează numărul de elemente din tabelul de culori apalColor Aceste două câmpuri sunt similare cu câmpurile din structura PALOBJ Motorul GDI stochează adresele a două funcții, pGetNearest și pGetMatch, în structura EPALOBJ Pe mașina autorului, câmpul pGetNearest se referă la win k!ulIndexedGetNearestFromPalEntry și câmpul pGetMarch la ulIndexedGetMatchFromPalEntry (deși pe alte sisteme se pot referi la altceva) Driverele de dispozitiv nu funcționează direct cu structura EPALOBJ Fișierul winddi h definește o structură PALOBJ care conține un singur câmp ulReserved Pentru a accesa tabelul de culori, driverul de dispozitiv trebuie să apeleze funcția motorului grafic PALOBJ cGetColors Există o analogie cu structura XLATEOBJ, pentru accesarea căreia este definită și funcția specială XLATEOBJ cGetPalette Regiunile din motorul GDI O regiune este definită ca o colecție de puncte de pe suprafața unui dispozitiv grafic Poate fi sub forma unui dreptunghi, poligon, elipsă sau orice combinație a acestor forme Operațiile de umplere, inversare și trasare sunt definite pentru regiuni; ele sunt, de asemenea, utilizate în tăierea sau testarea lovirii Probabil cea mai comună utilizare a regiunilor este în tăierea Regiunile sunt printre obiectele gestionate de GDI Regiunile noi sunt create de funcții precum CreateRectRgn, CreateRoundRgn și CreateEllip-ticRgn Unirea regiunilor existente se realizează prin operații logice Toate aceste funcții returnează un mâner de obiect GDI, HRGN, care este utilizat în apelurile ulterioare ale funcției GDI După cum se arată în secțiunea Structuri de date în modul utilizator, GDI stochează coordonatele regiunilor dreptunghiulare în structurile de date în modul utilizator Pentru alte regiuni, informațiile sunt stocate în spațiul de adrese kernel Structuri de date în modul kernel Extensia de depanare GDI oferă o comandă dr pentru a decoda un HRGN sau un pointer către o structură de date REGION în modul kernel Comanda listează chiar toate dreptunghiurile care alcătuiesc regiunea dată Mai jos sunt informațiile despre structura REGION obținute cu această comandă // Windows , dimensiune variabilă // Nu vă referiți direct la scnPntCntToo! typedef struct { LONG scnPntCnt; // Numărul de coordonate x LONG scnPntTop; // Limită superioară (activată) LONG scnPntBottom; // Limita inferioară (nu este inclusă) LONG scnPntX[ ]; // Matrice de lungime variabilă care conține x perechi LONG scnPntCntToo; // De asemenea ca scnPntCnt: }SCANĂ; // Windows , dimensiune variabilă struct REGIUNEA { hGDIOBJ hHmgr:// antetul obiectelor GDI în modul kernel vold*pentry:// ULONG cExcLock: // ULONG Tld: // c nesemnat slzeObj:// nesemnat unk [ ]; // SCANĂ*pscnTall:// c sizeRgn nesemnat: // cScanuri nesemnate; // RECTL rcl:// SCAN scnHeadEU; // }: Structura REGION începe cu un antet standard de octeți După cum sa menționat în secțiunea Structuri de date în modul utilizator, GDI simplifică crearea de regiuni cu un singur dreptunghi prin asocierea unei structuri RECT în modul utilizator cu un handle GDI Procedând astfel, GDI leagă obiectul regiune la procesul creator Pentru a menține această asociere, mecanismul GDI stochează ID-ul firului de execuție al programului care a creat obiectul în antet Structura REGION are o dimensiune variabilă Conține toate informațiile despre regiune, al căror volum poate fi crescut sau micșorat ca urmare a aplicării operațiunilor în regiune De exemplu, dacă o regiune este combinată cu o altă regiune utilizând operația RGN OR, dimensiunea structurii va crește de obicei, în timp ce dacă este utilizată operația RGN AND, de obicei va scădea Pentru a reduce numărul de alocări/dealocari, motorul GDI nu alocă exact dimensiunea blocului de memorie necesar pentru a reprezenta o regiune; în schimb, alocă un bloc puțin mai mare, permițând regiunii să crească fără realocarea memoriei Probabil, dimensiunea structurii REGION atunci când memoria este alocată este stocată în câmpul slzeObj, iar dimensiunea reală utilizată este în câmpul sizeRgn Capitolul Structuri interne de date GDI/DirectDraw Câmpul gci stochează datele dreptunghiului care delimitează regiunea Cele mai importante date din structura REGION sunt o serie de structuri SCAN Câmpul cScans stochează numărul de structuri din matrice, iar câmpul pscn se referă la adresa care urmează sfârșitului ultimei structuri din matrice De obicei, programatorii nu stochează indicatori de acest fel, deoarece sunt ușor de calculat din adresa de pornire, numărul și dimensiunea elementelor Cu toate acestea, este interesant de observat aici că structura SCAN are o dimensiune variabilă Nu este documentat în Windows NT/ DDK, deși versiunea pe biți a acestei structuri este documentată în Windows DDK Structura SCAN conține informații despre o „linie de scanare” a regiunii, a cărei înălțime în sistemul de coordonate poate fi egală cu un pixel (sau poate să nu fie egală) Mai exact, SCAN stochează informații despre intersecția unei regiuni cu o zonă delimitată de două linii orizontale, cu condiția ca intersecția conturului regiunii cu această zonă să fie formată doar din segmente verticale Motorul GDI împarte regiunea într-o secvență de structuri SCAN de sus în jos Deoarece punctele de intersecție ale conturului regiunii cu limitele SCAN superioare și inferioare au aceleași coordonate x, motorul GDI stochează doar una dintre ele Deci, structura SCAN stochează valorile coordonatelor la marginile superioare și inferioare, perechi de valori de coordonate x pentru intersecții și două copii ale numărului de intersecții Prin urmare, pentru regiunile complexe (de exemplu, cele cu găuri interne), structura SCAN salvează memoria necesară pentru a reprezenta regiunea Primul și ultimul câmp din structura SCAN stochează două copii ale numărului de intersecții Deoarece dimensiunea structurii SCAN este variabilă, ultimul său câmp nu are un offset fix de la începutul structurii Poate aveți o întrebare - de ce structurile REGIUNE și SCAN sunt aranjate atât de ciudat? Mecanismul GDI are motive întemeiate pentru aceasta Regiunile sunt de obicei trecute la funcțiile driverului grafic ca structuri CLIPOBJ Interfața DDI nu oferă acces la structura internă de date a CLIPOBJ; în schimb, permite driverelor grafice să enumere toate dreptunghiurile care alcătuiesc o regiune folosind funcția CLIPOBJ bEnum Driverul poate specifica ordinea în care sunt enumerate dreptunghiurile folosind funcția CLIPOBJ cEnumStart Mecanismul GDI permite enumerarea de la stânga la dreapta, de sus în jos; dreapta la stânga, de sus în jos; de la stânga la dreapta, de jos în sus etc - în orice ordine convenabilă pentru GDI Câmpul pscanTail al structurii REGION permite motorului GDI să sară rapid la ultima structură SCAN Câmpul scnPntCount vă permite să săriți rapid de la stânga la dreapta sau la următoarea structură SCAN atunci când este enumerată de sus în jos Câmpul scnPntCountToo oferă un salt rapid de la dreapta la stânga sau la următoarea structură SCAN atunci când este enumerat de jos în sus Următorul exemplu demonstrează modul în care structura REGION are legătură cu regiunile cunoscute nouă din API-ul Win Când creați o regiune cu funcția CreateEllip-ticRgn( , , , ), obțineți un handle de regiune Specificați-l când apelați comanda dr a extensiei GDI; depanatorul afișează adresa structurii REGION și o listă a tuturor dreptunghiurilor care alcătuiesc regiunea Structura REGIUNE conține de structuri SCAN cu casetă de delimitare [ , , , ] În tabel este o listă prescurtată de elemente ale matricei de structuri SCAN Structuri de date în modul kernel Tabelul Matrice de structuri SCAN într-o structură REGION (pentru un cerc) Cnt Sus Jos X[] CntToo -maxint - , , , , , , , maxint Din exemplul de mai sus, se poate observa că structura REGION conține o aproximare a figurii originale sub forma unei combinații de dreptunghiuri specificate prin coordonate întregi Prin urmare, dacă creați un manipulator GDI pentru o regiune și apoi îl scalați (folosind funcțiile GetRegionData și ExtCreateRegion cu parametrul XFORM), rezultatul va diferi de cel obținut prin procedura inversă (scalarea preliminară prin metode matematice și crearea ulterioară a manipulator GDI) Structura REGIUNE descrie regiunea de la stânga la dreapta, de sus în jos Coordonatele de sus și din stânga sunt incluse în regiune, dar coordonatele de jos și din dreapta nu sunt incluse Atunci când creează structuri REGION, GDI încearcă să fie cât mai precis posibil, motiv pentru care multe structuri SCAN au doar un pixel înălțime De exemplu, primele și ultimele structuri SCAN pentru un cerc corespund dreptunghiurilor care au o înălțime de pixel Dar acolo unde este posibil, GDI crește SCAN-ul la înălțimea maximă posibilă pentru a economisi memorie De exemplu, partea centrală a unui cerc este aproximată printr-un dreptunghi cu înălțimea , care corespunde structurii medii SCAN din matrice (coordonatele de la la ) Pentru a reprezenta cu exactitate regiunile care nu au o structură dreptunghiulară pronunțată, dimensiunea structurii REGIUNE este de obicei direct proporțională cu înălțimea regiunii și mai puțin dependentă de lățimea regiunii De exemplu, dublarea înălțimii unei elipse poate dubla dimensiunea REGIUNII, în timp ce dublarea lățimii REGIUNII ar putea să nu modifice deloc dimensiunea REGIUNII Numărul de structuri SCAN și dimensiunile REGIUNII afectează direct funcționarea motorului GDI, utilizarea memoriei de către driverele de dispozitiv și performanța generală, în special în modurile de imprimare de înaltă rezoluție pe imprimante de calitate În exemplul din tabel acordați atenție primei și ultimei structuri SCAN Nu corespund fragmentelor din regiune, adică nu conțin Capitolul Structuri interne de date GDI/DirectDraw coordonatele x În esență, aceste structuri afirmă că în intervalele y = [maxint - ] și [ , maxint] nu există regiuni în sistemul de coordonate care să aparțină acestei regiuni Dacă aceste structuri nu descriu părțile vizibile ale regiunii, de ce sunt stocate în spațiul prețios de adrese al nucleului? Răspunsul este simplificarea implementării și unificarea operațiunilor cu regiuni De exemplu, când inversați o regiune, vă puteți descurca cu același număr de structuri SCAN; este suficient să includeți în fiecare structură SCAN valorile -maxint - și maxint ca primele și ultimele coordonate x O regiune goală este reprezentată de o structură REGIUNE cu o casetă de delimitare { , , , } și o singură structură SCAN { , -maxint - , maxint, } Ați observat vreodată că atunci când apelați o funcție GDI pentru a crea o regiune circulară la coordonatele , , , , obțineți înapoi o regiune cu o casetă de delimitare de , , , , care încă nu include marginile din dreapta și de jos? Cu alte cuvinte, CreateEl și pti cRgn creează o formă mai mică decât ar fi creat-o funcția El lipse Da, aceasta este realitatea dură a Windows Acest defect cunoscut, care a supraviețuit de la Windows la Windows , este documentat în MSDN Win SDK (articolul Q ) Structura REGION rămâne închisă atât pentru programatorii de aplicații din API-ul Win , cât și pentru programatorii de drivere de dispozitiv din interfața DDL Singura structură de regiune de nivel scăzut disponibilă în API-ul Win este structura RGNDATA utilizată de funcțiile GetRegionData și ExtCreateRegion În RGNDATA, în loc de matricea SCAN, există o matrice de dreptunghiuri Interfața DDI folosește structura abstractă CLIPOBJ Pentru a obține dreptunghiurile care formează regiunea, trebuie să apelați funcția CLIPOBJ bEnum Trasee de scule în motorul GDI O cale este o colecție de forme (sau forme geometrice) cărora li se aplică operații de umplere, contur sau umplere și contur Puteți utiliza API-ul Win pentru a crea calea, dar nici măcar nu veți obține un control asupra obiectului creat Orice programator sănătos înțelege că este necesară o structură internă de date pentru a reprezenta traseul sculei în timpul construcției și utilizării ulterioare în GDI Motorul grafic Windows (win k sys) exportă chiar și un grup destul de mare de funcții pentru a efectua operațiuni pe obiectele traseului instrumentelor din driverele de dispozitiv Conform extensiei de depanare GDI, obiectele traseului de instrumente sunt prezente în tabelul de obiecte GDI Comanda dumpobj PATH afișează informații despre toate obiectele cale din sistem Extensia de depanare GDI nu conține comenzi pentru a decoda mânerul obiectului calea instrumentului sau structura de date corespunzătoare în modul kernel (în acest sens, căile de instrumente diferă și de alte tipuri de obiecte GDI) Comanda dpo decodifică doar structura PATHOBJ transmisă funcțiilor motorului GDI sau funcțiilor driverului de dispozitiv, cum ar fi EngStrokePath sau DevStrokeAndFillPath Următoarele informații despre structurile de date care reprezintă traseele sculei în motorul GDI au fost obținute folosind mai multe teste Structuri de date în modul kernel obiecte de ieșire a traiectoriei, precum și documentația Win API și DDK Structura principală a primit numele RATH // Windows dimensiune variabilă typedef struct PATHDT { -PATHDT pentru a descărca intrarea din tabelul obiect GDI corespunzătoare unui anumit handle Ieșirea comenzii preia un pointer către o structură PATH care conține un pointer către o structură PATHDEF Structura PATHDEF este definită după cum urmează: // Un exemplu de structură PATHDEF : unk x ' : pTail & pathdt[ ] : nAllocSizeOxfc c: pathdtEO] și pathdt[l], NULL, , , , , , , , , : pathdtEl] NULL și pathdt[ ], x , , , , , , , , , , , : pathdt[ ] Motorul GDI a alocat un bloc de de octeți (OxfcO) pentru a stoca traiectoria, în care sunt ocupați în prezent doar ( x ) de octeți Există încă suficient loc pentru creșterea viitoare a acestei traiectorii Structura PATHDEF stochează două structuri PATHDT într-o listă dublu legată Prima structură PATHDT constă din două puncte cu steagurile PD BEGINSUBPATH|PD RESETSTYLE Deci, avem două puncte care formează un segment A doua structură PATHDT constă din trei puncte cu steagurile PD ENDSUBPATH|PD BEZIERS Descrie o singură curbă Bezier care continuă de la punctul anterior și completează subtrajectoria Structura PATHDEF reproduce fidel toți parametrii specificați în codul Win Acum știm că structura PATH vă permite să reprezentați segmente de linie și curbe Bezier, precum și combinațiile lor arbitrare De exemplu, apelurile la funcțiile CloseFigure, LineTo, MoveToEx, PolyBezier, PolyBezierTo, Polygon, PolylineTo, PolyPolygon și PolyPolyline sunt ușor convertite în secvențe de linii și curbe Bezier Pe de altă parte, Windows / vă permite să includeți apeluri către TextOut și ExtTextOut în construcția traiectoriilor Cum este reprezentat textul în structura PATH? Se pare că atunci când construiești trasee, poți folosi doar fonturi ThyeType și doar contururile liniilor de text sunt scrise în cale, care sunt de fapt curbe Bezier Pe lângă funcțiile enumerate, Windows NT/ vă permite să includeți curbe eliptice în traiectorie De exemplu, atunci când construiți o traiectorie, puteți utiliza funcțiile AngleArc, Are, ArcTo, El lipse, Pie, etc Cum rezolvă mecanismul GDI această problemă? Curbele eliptice sunt împărțite în secvențe de curbe Bézier, similar cu modul în care regiunile non-dreptunghiulare sunt defalcate în Capitolul Structuri interne de date GDI/DirectDraw grupuri de linii de scanare Să presupunem că două comenzi suplimentare sunt incluse în fragmentul de mai sus înainte de a apela EndPathO: CIoseFlgure(hDC): ElipseChDC - , - , , ): Funcția CloseFigureO completează a doua structură PATHDT (vezi mai sus) Funcția EllipseO adaugă o altă structură PATHDT la listă, un grup de curbe Bezier în puncte Primul punct începe o nouă formă, iar celelalte puncte formează curbe Bezier Motorul GDI aproximează elipsa folosind curbe Bezier Definițiile celor puncte de întrerupere sunt următoarele cale: { - } { - } { , - ) {- , - } { - , - } { - - , } { - - , } {- , } { - , } {- , } { , } { } { ,- , } Devine clar de ce sunt folosite coordonatele FIX în structura PATH Rotunjirea coordonatelor la numere întregi va distorsiona forma elipsei Structura PATH este folosită pentru mai mult decât pentru stocarea traseelor de instrumente în Win GDI De asemenea, joacă un rol foarte important în DDI (interfața dintre motorul GDI și driverele dispozitivelor grafice) În special, apelurile la funcțiile de desen de linii (cum ar fi LineTo și PolyBezier) sunt traduse în apeluri la funcția DrvStrokePath, căreia îi este transmis un pointer către o structură PATHOBJ Funcțiile pline de regiune (cum ar fi El lipse și Polygon) sunt convertite în apeluri la funcția DrvStrokeAndFil Path, căreia îi este transmis și un pointer către PATHOBJ În comparație cu Windows NT , Windows a adăugat un nou punct de intrare DrvLineTo care îmbunătățește performanța pentru apelurile LineTo cu coordonate întregi ale punctului final Structura PATHOBJ este, de asemenea, una dintre structurile DDI „mascate” și conține doar două câmpuri publice Puteți utiliza funcțiile GDI pentru a obține informații despre componentele unei căi de scule, pentru a construi noi trasee de instrumente sau pentru a extinde o cale de instrumente prin includerea de noi curbe De exemplu, funcția EngCreatePath creează un nou obiect PATHOBJ; funcția PATHOBJ^ bPolyBezier include curbele Bezier în traseu; funcția PATHOBJ bEnum enumerează intrările componente ale căii într-o structură PATHDATA, foarte asemănătoare cu structura PATHDT descrisă mai sus Fonturi în motorul GDI Ceea ce sunt denumite în mod obișnuit fonturi în Win API ar fi mai corect numite „fonturi logice” Fonturile logice sunt create de funcțiile CreateFont, CreateFontIndirect și CreateFontDirectEx Când funcția este apelată, sunt specificate caracteristicile pe care ar trebui să le aibă fontul GDI (sau mai degrabă, sistemul de înlocuire a fonturilor, font mapper) găsește fontul fizic care se potrivește cel mai bine cerințelor Structuri de date în modul kernel Referințele de fonturi logice generate de GDI folosesc manipulatoare de tip HFONT În extensia de depanare GDI, obiectele font sunt notate prin tipul LFONT De exemplu, comanda dumpobj LFONT listează manipulatorii tuturor fonturilor logice de pe sistem Prin trecerea unui manipulator de font logic la comanda heif, obțineți informații despre structura de date asociată cu acel manipulator în spațiul de adrese kernel Comanda pur și simplu aruncă structura LOGFONTW corespunzătoare // Windows , ? octet typedef struct g HGDIOBJ hHmgr; // , antetul obiectelor GDI void* pentry; // ULONG cExcLock; // ULONG Tld: // c nesemnat unk [ ]; // PDEV WIN K*ppdev; // c nesemnat unk [ ]; // HGDIOBJ hPFE; // nesemnat unk [ ]; // WCHAR Face[ ]; // Odo nSize nesemnat; // ENUMLOGFONTEXW enumlogfontex; // } LFONT; De fapt, datele stocate în spațiul kernel pentru fonturile logice nu se limitează în niciun caz la structura LOGFONTW expusă de extensia GDI Chiar și funcția GetObject returnează o structură de de octeți pentru mânerul fontului logic, mai mult ca o structură ENUMLOGFONTEXW Primul său câmp este într-adevăr o structură LOGFONTW Un alt domeniu care merită atenție este indicatorul către structura dispozitivului fizic al motorului GDI Prin urmare, în motorul GDI, structura LFONT suportată pentru un font logic este de fapt o structură LOGFONTW cu câteva câmpuri suplimentare care formează o structură ENUMLOGFONTEXW, ceea ce are sens Dar unde sunt stocate informațiile de corespondență dintre fonturile logice și cele fizice? Și cum sunt transmise informațiile despre font către funcțiile driverului dispozitivului grafic, cum ar fi DrvTextOut? Extensia GDI Debugger arată o altă structură de date GDI nedocumentată, PFE Mânerul structurii PFE este stocat în câmpul hPFE al fiecărei structuri LFONT Puteți obține o listă cu toate mânerele PFE cu comanda dumpobj PFE a extensiei GDI Debugger și apoi utilizați comanda pfe pentru a obține informații despre structura nucleului PFE Structura nucleului PFE este următoarea: // Windows , (Oxbs) octeți struct PPF; typedef struct { HGDIOBJ hHmgr; // OOO antetul obiectelor GDI în modul kernel Capitolul Structuri interne de date GDI/DirectDraw void* pentry; // ULONG cExcLock: // ULONG Tid; // c pff*pFFF:// pff Font ULONG i: // ULONG flPPE:// FD-GLYPHSET *pfdg:// c gs void * unk : // f ddef IFIMETRICS * pi fi: // ifi idif nesemnat: // void*pkp; // c nesemnat i dkp; // nesemnat ckp:// nesemnat iOrientation:// nesemnat cjEfdwPFE:// c void*pgiset; // ulTimeStamp nesemnat; // nesemnat ufi:// nesemnat unk c:// c nesemnat pid:// ql nesemnat; // nesemnat unk ; // void *pFlEntry; // c cAlt nesemnat: // cPfdgRef nesemnat; // aiFamilyName nesemnat; // }PFE: Structura PFE începe cu un antet de obiect GDI standard de lungime octeți Câmpul pPFF se referă la o structură PFF care conține informații despre fișierul de font fizic Structura PFF este descrisă mai târziu în această secțiune Câmpul pfdg stochează un pointer către structura FD GLYPHSET documentată în SDK Structura FD GLYPHSET definește maparea caracterelor Unicode la mânerele de glif interne Caracterele Unicode sunt reprezentate de valori pe biți Unicode acceptă mii de caractere diferite, iar fonturile pot fi limitate la un mic subset al acestei codificări Un font este o colecție de glife, cărora fiecăruia îi este atribuit un mâner unic Folosind structura FD GLYPHSET, motorul GDI mapează caracterele Unicode la manipulatorii de glif Extensia de depanare GDI oferă o comandă gs pentru a decoda structura FD GLYPHSET De exemplu, pentru fontul Small Fonts (smalf fon), această comandă arată că fontul are de glife Gliful caracterului spațiu corespunde mânerului , gliful caracterului „A” tratează x și așa mai departe De asemenea, rețineți câmpul pi fi, care conține un pointer către structura IFIMETRICS, documentat și în DDK Structura IFIMETRICS conține informațiile căștilor utilizate de GDI Mai exact, stochează nume de familie, stil și tipare, un nume unic, capabilități de emulare, un ID de implementare și, în final, o matrice panoramă de octeți care descrie caracteristicile vizuale ale fontului Structura IFIMETRICS este completată cu funcția Structuri de date în modul kernel ei DrvQueryFont Extensia de depanare GDI oferă o comandă ifi pentru a decoda structura IFIMETRICS De exemplu, pentru fonturi mici, comanda returnează informații despre formatul bitmap de bit/pixel, scalarea întregului și rotirea la ° și emularea bold, italic și bold-italic Fontul logic este asociat cu un anumit proces Win Când un proces este oprit, toate mânerele GDI ale sale sunt distruse și intrările din tabelul de obiecte sunt eliberate pentru reutilizare Cu toate acestea, manipulatoarele PFE există la nivel de sistem și nu sunt asociate cu procese specifice Mai multe fonturi logice pot fi asociate cu o singură structură PFE Structura PFF descrie un fișier de font fizic După cum ați putea ghici, extensia GDI are și o comandă pff pentru a decoda această structură Definiția unei structuri PFF arată astfel: struct RFONT; typedef struct PFF LONG sizeofThis; // PFF* pPFFNext; // , pff PFF*pPFFPrev; // ,pff WCHAR*pwazPathName // c ULONG cwc; // ULONG cFiles; // nesemnat unk [ ]; // ULONG flState; // ULONG încărcat; // ULONG cNotEnum; // ULONG cRFONT; // c RFONT * prfntList; // , fo void*hff; // void*hdev; // dhpdev nesemnat; // c void*pfhFace; // void*pfhFamily:// void*pfhUFI; // void*pPFT; // c, pft ULONG ulCheckSuml; // nesemnat unk ; // ULONG cFonts; // void*ppfv; // c void *pPvtDataHead; // nesemnat unk ; // PFE*pPFE; // pfe WCHAR wszStrings[l]; // c }PFF; Structurile PFF din motorul GDI sunt combinate în liste dublu legate Legăturile către elementele următoare și anterioare sunt stocate în câmpurile pPFFNext și pPFFPrev Următorul câmp conține un indicator către numele fișierului font de pe disc Capitolul Structuri interne de date GDI/DirectDraw ke - de exemplu, „\??\C:\WIN \FONTS\SMALLF FGN”, care are setat indicatorul PFF STATE PERMANENT FONT în câmpul fl State Câmpul cLoaded stochează un flag care indică dacă fișierul a fost încărcat în memorie; câmpul cRFONT stochează numărul de fonturi implementate pe baza fontului fizic, iar câmpul prfntLi st se referă la primul element al listei de fonturi implementate Câmpul pPFT conține un pointer către o structură PFT, care este un tabel cu structuri PFF Structura PFT este decodificată de comanda pft și arată astfel: typedef struct { void *pfhFamlly; // void*pfhFace; // void*pfhUFI:// ULONG cGăleți: // c ULONG cFiles:// PFF*apPFFEl]: // }PFT: Primele trei câmpuri ale structurii PFT stochează indicatorii către trei tabele hash care sunt decriptate de comanda fh Tabelele hash sunt concepute pentru a stabili rapid o corespondență între fonturile logice și fizice În structura PFT, datele fonturilor sunt stocate într-un tabel hash, calculat, după cum arată experimentele, pentru de elemente Structura PFT stochează un pointer către prima structură PFF din lista dublu legată creată de cele două câmpuri de referință ale structurii PFF Câmpul cFiles stochează numărul total de fișiere de font combinate în structura PFT Motorul GDI creează trei tabele de structură PFF - unul pentru fonturile deschise, unul pentru fonturile private și unul pentru fonturile dispozitivului Indicatorii către aceste tabele sunt stocați în trei variabile globale - win k!gpPFTPublic (fonturi publice), win k!gpPFTPrivate (fonturi private) și win k!gpPFTDevice (fonturi pentru dispozitiv) Extensia de depanare GDI folosește aceste variabile în trei comenzi care afișează conținutul a trei tabele: pubft, pvtft și devft Lista de fonturi afișată de comanda pubft arată cam așa: apPFF[ ] ”\??\С:\WIN \FONTS\TREUCBD TTF” „\??\C:\WIN \FONTS\CGA W A FON” apPFF[ ] „\??\C:\WIN \FONTS\MICROSS TTF” apPFF[ ] „\??\C:\WIN \FONTS\PALA TTF” apPFF[ ] „\??\C:\WIN \FONTS\TIMES TIF” Este timpul să descriem cea mai importantă structură de fonturi ale driverului grafic, FONTOBJ, și versiunea sa extinsă, RFONT S-a spus mai sus că structura LFONT descrie un font logic, adică o solicitare pentru un font cu o dimensiune și unghi de rotație date, caracteristici speciale (de exemplu, saturație), etc Pe de altă parte, un fișier de font descris prin structura PFF este un șablon generic care poate fi scalat la diferite dimensiuni, rotit în unghiuri diferite și extins cu alte caracteristici specifice În forma sa cea mai simplă, pentru fiecare caracter dintr-un șir de text, motorul GDI apelează driverul de font pentru o descriere Structuri de date în modul kernel conturul general al simbolului, îl scala la dimensiunea dorită, îl rotește la unghiul dorit, îl transformă într-un raster, îl folosește și uită de existența lui Totuși, în cazul general, o astfel de schemă este extrem de ineficientă, mai ales având în vedere că pentru fonturile pe un singur octet cu un număr mic de caractere, memorarea în cache este ușor de organizat, economisind mult timp prin construirea în mod repetat a bitmap-urilor pentru fiecare font Pentru a face acest lucru, mecanismul GDI folosește structura RFONT Structura RFQNT descrie o implementare specifică sau, dacă preferați, o instanță specifică a unui font Nu este un font logic sau fizic, ci un set de glife create conform cerințelor fontului logic pe baza unei descrieri generice preluate din fișierul fontului Prima parte a structurii RFONT este documentată în DDL ca structură FONTOBJ, acest lucru este făcut pentru a accelera apelurile de la driverele grafice Câmpurile rămase ale structurii RFONT pot fi accesate numai prin metode speciale ale structurii FONTOBJ, cum ar fi FONTOBJ cGetGlyphHandles și FONTOBJ cGetGlyphs În extensia de depanare GDI, structura RFONT este decodificată folosind comanda fo Următoarea este o definiție voluminoasă a structurii RFONT typedef struct { void *pgdNext; void *pgdThreshold; void *pjFirstBlockEnd; void *pdblBase; ULONG cMetrics; ULONG cjbbl: ULONG cBlocksMax: ULONG cBlocks; cGlyphs ULONG; ULONG cjTotal: void*pbblBase; void *pbblCur: void*pgbNext; void*pgbThreshold; void*pjAuxCacheMem; void*cjGlyphMax; void*bSmallMetrics: ULONG i Max; ULONG iFirst; Biți LONG; }CACHE; struct RFONT { FONTOBJ fOb j ; // ULONG iUnique; // c ULONG fl Tour; // ULONG ulContent; // PVOID hdevProducer; // ULONG hDeviceFont; // c PVOID hdevConsumer; // DHPDEV dhpdev; // PFE*ppfe:// Capitolul Structuri interne de date GDI/DirectDraw PFF*ppff; // c FD XF RM fdx; // ULONG cBitsPerPel; // MATRIX mxWorldToDevice; // ULONG IGraphicsMode; // OaO FLOATOBJ eptf NtoWScale x ; // a FLOATOBJ eptflNtoWScale y i://Oac ULONG bNtoWIdent: // b MATRIX xoForDDI pmx; // b ULONG xoForDDIjjlMode; // obc nesemnat unk OOO: //OcO MATRIX mxForDDI; // c ULONG flRealizedType; // POINT ptlUnderlinel; // POINT ptlStrikeOut; // c PTlULThlckness: // POINT ptlSOGrosimea; // c ULONG Charlnc; FIX fxMaxAscent; FIX fxMaxDescent; FIX fxMaxExtent: pOlntFX ptfxMaxAscent; pOintFX ptfxMaxDescent; ULONG cxMax: LUNG IMaxAscent: LUNG IMaxHelght; ULONGcyMax: ULONG cjGlyphMax; FD XFORM fdxQuantlzed: LONG INonLinearExtLeadlng; LONG INonLINEarlntLeadlng; LONG NonLi nearMaxCharWi dth: LONG INonLINEarAvgCharWldth; ULONG ulOrientathlon; FLOATOBJ pteUnitBase x: FLOATOBJ pteUnitBase y; FLOATOBJ efWtoBase: Ascensiunea LUNGA; FLOATOBJ pteUn tAscent x: FLOATOBJ pteUnitAscent y; FLOATOBJ efWtoDAscent; FLOATOBJ efDtoWAscent; FLOATOBJ efWtoDEsc: FLOATOBJ efDtoWesc: FLOATOBJ efEscToBase; FLOATOBJ efEscToAscent; ULONG info; ULONG hgBreak; ULONG fxBreak; vold*pfdg; void*wcgp; ULONG cSelectat; RFONT * rflPDEV-prfntPrev; RFONT * rflPDEV-prfntNext; RFONT*rflPFF-prfntPrev; Structuri de date DirectDraw RFONT * rflPFF prfntNext; void*hsemCache; cache CACNE; POINT ptlSim; ULONG bNeededPaths; FLOATOBJ efDtoWBase ; FLOATOBJ efDtoWAscent ; TEXTMETRICW*ptmw; LONG IMaxNegA; LONG IMaxNegC: LONG IMinWidthD: ULONG blsSystemFont: ULONG FLEUDCstarea: RFONT * prfntSystemTT; RFONT*prfntSysEUDC; RFONT*prfntDefEUDC; void*paprfntFaceName; void * aprfntQui ckBuffE J ULONG bFilledEudcArray: ULONG ulTimeStamp: ULONG ui Nunti nks ; ULONG bVertical; ULONG pchKernelBase; ULONG iKernelBase; Văzând o structură de date atât de complexă, puteți fi sigur că motorul GDI \ face tot posibilul pentru a optimiza textul Alte obiecte GDI din motorul GDI Deci, ne-am uitat la structurile de date care reprezintă principalele obiecte GDI din spațiul de adrese kernel În special, au fost descrise structuri de date pentru contextul dispozitivului, bitmap independent de dispozitiv, secțiune DIB, pensulă, creion, paletă, regiune, cale, font logic, fonturi fizice și implementate Ieșirea dumphmgr a extensiei de depanare GDI menționează și alte tipuri de obiecte, cum ar fi DD DRAW TYPE, CLIOBJ TYPE și SPOOL TYPE Obiectele legate de DirectDraw sunt descrise în secțiunea următoare Alte obiecte nu sunt tratate în acest capitol pentru că fie nu joacă un rol deosebit în programarea Win , fie sunt învechite odată cu evoluția sistemului de operare Windows, fie nu avem mijloacele pentru a le instanția Veți vedea în curând că cunoașterea elementelor interne ale structurilor de date GDI vă ajută să obțineți o înțelegere mai profundă a programării Win GDI API Structuri de date DirectDraw „Dă-mi un manipulator și îți voi arăta structura datelor” De fapt, aceasta este problema care a fost rezolvată în acest capitol în legătură cu obiectele GDI Am aflat că există un tabel global de obiecte GDI în sistem, acel GDI Capitolul Structuri interne de date GDI/DirectDraw creează structuri de date pentru unele obiecte în spațiul de adrese în modul utilizator și pentru toate obiectele sunt create structuri de date pe care motorul GDI le stochează în spațiul de adrese în modul kernel Cu ajutorul extensiei de depanare GDI, investigăm treptat legăturile nedocumentate dintre GDI și DDI Și acum să trecem la DirectDraw - API-ul erei COM (Component Object Model) Când creați un obiect DirectDraw sau o suprafață DirectDraw, în loc de manipulatoare (să spunem HDIRECTDRAW sau HDIRECTSURFACE), vi se oferă mânere de interfață LPDIRECTDRAW și LPDIRECTDRAWSURFACE Ce să faci cu ei? Conceptual, o interfață COM este un grup de funcții legate semantic care oferă acces la un obiect COM La nivel de implementare, o interfață COM este reprezentată de un tabel de funcții virtuale care conține adresele funcțiilor legate semantic Un pointer de interfață COM este de obicei definit ca un pointer către o interfață COM De fapt, un pointer de interfață COM se referă la un obiect COM (adică o instanță a unei clase) Luați în considerare un exemplu de creare a unui obiect COM pentru DirectDraw: HRESULT DirectDrawTest (HWND hWnd) { LPDIRECTDRAW Ipdd; HRESULT hr = DirectDrawCreate(NULL & Ipdd, NULL): dacă ( hr == DD OK) { lpdd->SetCooperativeLevel(hWnd DDSCL NORMAL): DDSURFACEDESC ddsd: ddsd dwSize = sizeof(ddsd); ddsd dwFlags = DDSD CAPS: ddsd ddsCaps dwCaps = DDSCAPS PRIMARYSURFACE: LPDIRECTDRAWSURFACE Ipddsprimary: hr = lpdd->CreateSurface(&ddsd &lpddsprimary NULL); dacă ( hr == DD OK) { mizerie de caractere[MAX PATH]: wsprintf(mizerie, „Obiect DirectDraw la Xx vtable la Xx\n” „Obiect de suprafață DirectDraw la fcx vtable la Xx” Ipdd * (nesemnat *) Ipdd Ipddsprimar * (nesemnat *) Ipddsprimary): MessageBox(NULL mess, „DirectDrawTest” MB OK): lpddsprimary->Release(): } lpdd->Release(): } ora de intoarcere: Structuri de date DirectDraw Fragmentul de mai sus creează un obiect DirectDraw și un obiect de suprafață DirectDraw, apoi trimite adresele și pointerii acestora către tabelele de funcții virtuale Dacă inserați un fragment într-un program și îl executați, pe ecran apare o casetă de mesaj cu un text similar cu următorul: Obiect DirectDraw la e a vtable la a Obiect de suprafață DirectDraw la e b vtable la Dacă programul a fost rulat într-un depanator, puteți verifica dacă obiectele sunt create din heap-ul din spațiul de adrese al utilizatorului și că pointerii către tabelele de funcții virtuale se referă la modulul de implementare DirectDraw ddraw dll După câteva minute de căutare, se pot găsi adresele funcțiilor din tabelele virtuale și numele lor simbolice De exemplu, un fragment din tabelul de funcții virtuale a obiectului DirectDraw arată astfel: E A : ddraw dll!DD QueryInterface EB : ddraw dll!DD AddRef EC : ddraw dll!DD Release C A: ddraw dll!DD Compact C B: ddraw dll!DD CreateC pper Am înţeles? Principiul utilizării adreselor și tabelelor de funcții în COM este foarte asemănător cu interfața DDI dintre motorul GDI și driverele grafice, deși este mult mai formalizat Acum să vedem cum se reflectă DirectDraw în tabelul de obiecte GDI Pentru a face acest lucru, vom folosi extensia corectă de depanare GDI sub controlul propriului program Fosterer Rulați comanda dumpdd de două ori, înainte de a executa fragmentul de mai sus și în timp ce caseta de mesaj este pe ecran (adică în timp ce obiectele DirectDraw nu au fost încă eliberate) Rezultatul nu este greu de prezis - descoperim două noi tipuri de obiecte, DD DIRECTDRAW TYPE și DDSURFACETYPE La implementarea DirectDraw în GDI, manipulatoarele sunt încă folosite, deși sunt ascunse de pointerii de interfață Evident, DD DIRECTDRAW TYPE corespunde unui obiect DirectDraw, iar DD SURFACE TYPE corespunde unui obiect de suprafață DirectDraw Să începem prin a ne uita la obiectul DirectDraw Toate obiectele DirectDraw sunt listate cu comanda dumpddobj DDRAW Structura de date în modul kernel este decodificată cu comanda dddlocal, care scoate numele structurii, EDDJHRECTDRAW LOCAL Motorul GDI distinge între o structură de date DirectDraw globală și o structură de date DirectDraw la nivel de proces Mai jos este definiția structurii DIRECTDRAW LOCAL EDD // Windows de octeți typedef struct { HGDIOBJ void * ULONG ULONG hHmgr; pentry; cExcLock: Tid; // , antet GDI // // // c EDD DIRECTDRAW GLOBAL * peDIrectDrawGlobal; // EDDJ)IRECTDRAW GLOBAL * peD rectDrawGloba! : // Capitolul Structuri interne de date GDI/DirectDraw EDD-SURFACE*peSurface Ddlist:// nesemnat unk c[ ]; // c EDD DIRECTDRAW LOCAL * peDirectDrawLocalNext; // FLATPTR fpProcess; // FLONG fl:// c MANEREA UniqueProcess; // Procesul PEPROCESS; // nesemnat unk [ ]; // void*unk ; // nesemnat unk ; // }EDD DIRECTDRAW LOCAL; Câmpul UniqueProcess al structurii EDD DIRECTDRAW LOCAL stochează ID-ul procesului Câmpul Process conține un pointer către obiectul kernel asociat procesului Mai mult, obiectul DirectDraw este asociat cu firul care l-a creat prin câmpul Tid (spre deosebire de majoritatea obiectelor GDI, care au de obicei un câmp Tid de ) Motorul GDI menține, de asemenea, o instanță a structurii de date globale EDD DIRECTDRAW GLOBAL care gestionează informațiile despre starea globală a DirectDraw În EDDJHRECTDRAW LOCAL, pointerii către această structură apar de două ori De obicei, un singur proces DirectDraw creează mai multe suprafețe DirectDraw Obiectele de bază ale acestor suprafețe sunt combinate într-o listă legată individual, începând cu câmpul peSurface DdList Toate obiectele DirectDraw aflate în prezent în sistem sunt, de asemenea, legate într-o listă folosind câmpul peDirectDrawLocalNext Structura EDD DIRECTDRAW LOCAL se află în fruntea ierarhiei tuturor obiectelor de proces DirectDraw și conține, de asemenea, referințe la alte obiecte globale din familia DirectDraw Ierarhia de rețea a structurilor DirectDraw permite coordonarea activității acestora Structura EDD DIRECTDRAW GLOBAL este decodificată de comanda dddglobal Definiția lui arată astfel: // Windows (OxlDC) octeți typedef struct { HDEV hdev; // x nesemnat unk ; // x SPRITE*pListZ; // x SPRITE*pListY; // x c SURFOBJ*psoScreen; // x nesemnat unk [ ]; // x FLONG f OriginaiSurfFlags; // x ULONG iOriginalType; // x c nesemnat unk [ ]; // x SPRITESCAN* pRange; // x void *pRangeLimit; // x SURFOBJ psoComposite; // x c nesemnat unk [ ]; // x REGIUNE * prgnDeblocat; // x nesemnat unkJ c[ ]; // x c } SPRITESTATE: // Windows , ( x ) octeți Structuri de date DirectDraw typedef struct { void*dhpdev:// x DWORD dwReservedl:// x DWORD dwReserved : // x nesemnat unk c[ ]; // x c LONG cDriverReferences: // x nesemnat unk c[ ]: // x c LONGLONG AssertModeTimeout; // x DWORD dwNumHeaps; // x VIDEOMEMORY *pvmList:// x DWORD dwNumFourCC:// x DWORD *pwdFourCC:// x c DD HALINFO ddhalinfo:// x nesemnat unk le [ ]: // OxleO DD CALLBACKS ddcalIbacks:// x DD SURFACECALLBACKS ddsurfacecallbacks:// x c DD PALETTECALLBACKS ddpalettecal Ibacks: // x ? nesemnat unk [ ]; // x D DNTHAL CALLBACKS d dnthalcal Ibacks: // x d nesemnat unk [ ]: // x D DNTHAL CALLBACKS d dnthalcal backs :// x c nesemnat unk [ ]: // x DD MISCELLANEOUSCALLBACKS ddmiscellaneouscalIbacks: // x e nesemnat unk ec[ ]: // x ec D DNTHAL CALLBACKS d dnthalcallbacks :// x nesemnat unk c[ ]: // x c EDD DIRECTDRAWLOCAL * peDirectDrawLocalList:// x a EDD SURFACE * peSurface LockList:// x ac FLONG fl: // Ox bO ULONG cSurfaceLocks:// x b PKEVENT pAssertModeEvent: // x b EDD-SURFACE * peSurfaceCurrent:// x bc EDD-SURFACE * peSurfacePrimary:// x c BOOL bSuspendat: // x c nesemnat unk c [ ]: // x c RECTL rcBounds: // x f hdev hdev:// x nesemnat unk c:// x c }EDD DIRECTDRAW GLOBAL; Structura DIRECTDRAW GLOBAL EDD conține aproape toate informațiile de suport DirectDraw pe care motorul GDL trebuie să le cunoască Câmpul dhpdev deține mânerul structurii PDEV al driverului de dispozitiv, returnat de un apel către DrvEnablePDEV De obicei, este un pointer către o structură de date private a dispozitivului fizic Structura DIRECTDRAW GLOBAL EDD include câteva alte structuri primite de motorul GDI de la driverul de ecran Câmpul ddhalinfo conține structura DDJ ALINFO returnată de funcția DrvGetDirectDrawInfo care descrie capabilitățile hardware și ale driverului Câmpurile ddcal Ibacks, ddsurfacecall-backs și ddpalettecalIbacks stochează structurile DD CALLBACKS, DD SURFACECALLBACKS și DD PALETTECALLBACKS returnate de funcția DrvEnable eDirectDraw Alt grup Capitolul Structuri interne de date GDI/DirectDraw structuri se referă la funcțiile grafice D ale DirectDraw Ele furnizează motorului GDI informații despre punctele de intrare DirectDraw acceptate de șofer Astfel, motorul GDI știe ce funcții să apeleze la crearea unei suprafețe, atribuirea tastelor de culoare, maparea adreselor de memorie video, comutarea suprafețelor etc Structura DIRECTDRAW GLOBAL EDD stochează o mulțime de alte informații interesante, cum ar fi o listă de obiecte DirectDraw, o listă de suprafețe blocate, un pointer către suprafața curentă și așa mai departe Funcția EDD DIRECTDRAW GLOBAL face parte din structura PDEV WIN K descrisă în WinDbg și în extensia GDI Debugger Structura WIN K PDEV include și o structură SPRITESTATE După ce ne-am dat seama cum mecanismul GDI organizează stocarea datelor generale DirectDraw (atât date globale, cât și la nivel de proces), să vedem ce se află în spatele suprafețelor DirectDraw Fiecare obiect de suprafață DirectDraw are o structură de date asociată care este ascunsă utilizatorului În rezultatul comenzii dump-ddobj, aceste structuri sunt notate cu DD SURF TYPE Comanda dumpddobj SURF GDI aruncă toate mânerele de suprafață DirectDraw Când comanda dddsurface este invocată pe un anumit mâner de suprafață, este afișată structura de date în modul nucleu EDD SURFACE typedef struct { HGDIOBJ hHmgr; // OOO Antet GDI void* pentry; // ULONG cExcLock; // ULONG Tid; // c DD SURFACE LOCAL ddsurfacelocal; // DD SURFACE MORE ddsurfacemore:// c DD SURFACE GLOBAL ddsurfaceglobal; // DD SURFACE INT ddsurfaceint:// b EDD SURFACE * peSurface DdNext; // b EDD SURFACE * peSurface LockNext: nesemnat unk c ; //OcO EDD DIRECTDRAWGLOBAL * peDirectDrawGlobal; EDD DIRECTDRAWLOCAL * peDirectDrawLocal; FLONG fl; nesemnat unk OdO; // Odo ULONG iVisRgnUniqueness; nesemnat unk d ; MANEREA hSecure: nesemnat unk OeO; HWITMAR hbmGdi; // e nesemnat unk e ; ERECTL rclLock; //Oec: nesemnat unk fc[ ]; // Ofc }EDD SURFACE; Antetul obiectului GDI în modul kernel standard din structura EDD SURFACE este urmat de patru structuri documentate în Windows DDK: Structuri de date DirectDraw DD SURFACE LOCAL, DDSURFACEMORE, DD SURFACE GLOBAL și DD SURFACE INT Structura DD SURFACE-GLOBAL conține informații comune mai multor suprafețe - pitch (pitch), înălțime, lățime și coordonate x/y Structura DD SURFACE LOCAL conține date specifice unui anumit obiect de suprafață, cum ar fi buffer-uri primare și secundare, chei de culoare, format de pixeli, suprafețe atașate și așa mai departe Structura DD SURFACE MORE conține date suplimentare la nivel de suprafață, cum ar fi informații despre portul video și semnalizatoarele de suprapunere Ultima structură, DD SURFACE INT, conține un pointer către o structură DDSURFACELOCAL Structurile de suprafață DirectDraw documentate sunt urmate de indicatori către următoarea suprafață din listă, date globale și locale DirectDraw Câmpul hbmGdi stochează uneori mânerul DDB Știm cum funcționează unele structuri de date DirectDraw în modul kernel; dar cum se folosesc? Procesarea comenzilor grafice DirectDraw (cum ar fi comutarea suprafețelor) începe de obicei cu un indicator de interfață către o suprafață DirectDraw Mânerul DD SURF TYPE al obiectului GDI este determinat de la indicatorul de interfață la suprafață și transmis motorului GDI Motorul găsește structura EDD SURFACE și obține un pointer către structura EDD DIRECTDRAW GLOBAL, care conține structura DD SURFACECALLBACKS Structura SURFACECALLBACKS DD stochează un pointer către punctul de intrare al driverului de ecran care se ocupă de comutarea suprafeței și este apelat de motorul DirectDraw Funcției de comutare i se trece structura DD FLIPDATA, care este colectată din datele din structurile EDD SURFACE sursă și țintă Consultați descrierea DdFlip din DDK pentru detalii Înainte de lansarea Windows (build ), DirectX folosea un tabel de obiecte partajat cu GDI Comanda dumphmgr a extensiei de depanare GDI listează obiectele DirectX împreună cu obiectele GDI normale Obiectele DirectDraw au un identificator de tip intern de x , iar obiectele de suprafață DirectDraw au un identificator de tip intern de x Cu toate acestea, în versiunea oficială a Windows , Microsoft a scos obiectele DirectX de sub controlul managerului de gestionare GDI și le-a transmis managerului de gestionare DirectX Noi comenzi dumpdd și dumpdobj au fost adăugate la extensia de depanare GDI Managerul DirectX Manipulator gestionează șase tipuri de obiecte: obiecte la distanță, obiecte DirectDraw, obiecte de suprafață DirectDraw, obiecte dispozitiv Direct D, obiecte porturi video DirectDraw și obiect de compensare a mișcării DirectDraw Conform acestor noi comenzi, DirectX Handle Manager menține un tabel de K octeți cu de mânere DirectX, o versiune redusă a tabelului K Încă nu știm dacă este posibil să creștem dimensiunea tabelului de obiecte DirectX De asemenea, nu se știe în prezent dacă tabelul de obiecte DirectX este mapat la spațiul de adrese în modul utilizator, similar cu tabelul de obiecte GDI Fără îndoială, separarea obiectelor DirectX de obiectele GDI ar trebui considerată o mișcare bună, care asigură că aplicațiile DirectX nu intră în conflict cu aplicațiile GDI pentru un set limitat de handle GDI Capitolul Structuri interne de date GDI/DirectDraw Rezultate Acest capitol explorează structurile de date interne care stau la baza GDI și DirectDraw Analizează în detaliu organizarea reprezentării interne a datelor de serviciu GDI și motorul grafic Windows Capitolul începe cu o sarcină simplă - aflăm ce este un handle de obiect GDI Apoi găsim tabelul de obiecte GDI în memorie, descifrăm structura acestuia și unele dintre structurile de date în modul utilizator acceptate pentru anumite tipuri de obiecte GDI Cele mai importante structuri de date GDI sunt stocate în spațiul de adrese în modul kernel Pentru a putea citi conținutul acestor structuri, am dezvoltat un driver simplu în mod kernel, Periscope, și am rulat o extensie de depanare GDI sub propriul nostru program Deoarece extensia de depanare are informații despre elementele interne GDI, poate fi folosită pentru a decoda structurile de date GDI în modul kernel Extensia de depanare GDI vă ajută să accesați structurile de date GDI în modul kernel care sunt de obicei complet ascunse de cei din afară După ce ați citit acest capitol, ar trebui să aveți o idee mult mai bună despre cum GDI stochează intern datele, ce resurse sunt implicate și cum se realizează aproximarea În plus, ar trebui să aveți o înțelegere de bază a modului în care datele sunt convertite de motorul GDI și, în cele din urmă, sunt transmise driverelor pentru dispozitive grafice (cum ar fi driverele de afișare și de imprimantă) Capitolul descrie un utilitar simplu care se bazează pe materialul din acest capitol pentru a obține un rezumat al modului în care diferite procese utilizează obiectele GDI „Dă-mi un manipulator GDI și îți voi arăta structura de date GDI” „Dă-mi un indicator de interfață DirectDraw și îți voi arăta structura de date DirectDraw ” Acum aveți tot dreptul să faceți astfel de declarații Exemple de programe Programele din Capitolul (Tabelul ) nu sunt exemple obișnuite de programare grafică și nici măcar npo-grame Windows obișnuite Mai degrabă, acestea sunt utilitare de sistem care ajută la analizarea structurilor interne de date ale sistemului de operare Windows Desigur, le puteți folosi în propriile scopuri Tabelul Capitolul Programe Descriere director de proiect Samples\Chapt \Handles Decodificați mânerele GDI, căutați tabelul de obiecte GDI și decodificați tabelul de obiecte GDI Samples\Chapt \QueryTab Un exemplu de accesare a unui tabel de obiecte GDI dintr-o aplicație Rezultate Descriere director de proiect Samples\Chapt \Periscope Un driver de dispozitiv în modul kernel care permite ca datele din spațiul de adrese în modul kernel să fie manipulate din spațiul de adrese al utilizatorului utilizând operațiuni cu fișiere Samples\Chapt \T estPeriscope Un exemplu de accesare a spațiului de adrese kernel dintr-o aplicație Samples\Chapt \Fosterer Un program care gestionează DLL-ul extensiei de depanare GDI în modul kernel, un punct de plecare pentru investigarea structurilor de date GDI/DirectDraw în modul kernel Capitolul Monitorizarea sistemului grafic Windows Se spune că e mai bine să vezi o dată decât să auzi de o sută de ori Dacă vezi ce se întâmplă cu proprii tăi ochi, îți este mult mai ușor să înțelegi esența fenomenului Desigur, este de dorit să alegeți instrumentul potrivit pentru aceasta De exemplu, un microscop ajută la observarea celor mai mici ființe vii, stelele îndepărtate sunt vizibile printr-un telescop, iar un televizor aduce oamenii care trăiesc în diferite părți ale lumii mai aproape Programatorii care lucrează pe sistemul Windows sunt interesați în primul rând de ceea ce se întâmplă de fapt între programele lor și sistemul de operare Capitolul a descris arhitectura generală a sistemului grafic Windows, în timp ce capitolul sa concentrat pe structurile de date Dar, în același timp, dinamica milioanelor de apeluri care au loc în sistem a rămas complet ignorată Cum începe programul? Cum se termină? Totul merge întotdeauna bine sau în sistem apar accidente, încălcări, ambuteiaje și scurgeri pe care pur și simplu nu le observi? În acest capitol, veți învăța abilitățile de monitorizare a funcțiilor API și unele dintre instrumentele necesare pentru a înțelege dinamica apelurilor funcțiilor Win API, în special funcțiile Win GDI/DirectDraw, utilitățile sistemului grafic și interfața DDI În secțiunea „Urmărirea apelurilor de funcție API Win ”, este dezvoltat un sistem general de monitorizare Win API, care constă dintr-un DLL care este injectat în procesul țintă și un program de control În secțiunea Win GDI Call Monitoring, acest sistem general este extins pentru a monitoriza toate apelurile GDI dintr-un proces Secțiunea DirectDraw COM Tracing se concentrează pe interfețele COM utilizate în DirectDraw, în timp ce secțiunea GDI System Call Tracing ilustrează o tehnică de interceptare a apelurilor către funcțiile sistemului GDI În cele din urmă, în secțiunea „Monitorizarea interfeței DDI”, ne vom arunca înapoi în modul kernel și ne vom uita la procesul de monitorizare a funcțiilor DDI Urmărirea apelurilor de funcție API Win Urmărirea apelurilor de funcție API Win Tehnica de interceptare și urmărire nu este neobișnuită în programarea Windows Există multe programe profesionale și de amatori care folosesc aceste tehnici pentru a observa cele mai mici detalii ale sistemului Cel mai faimos instrument care folosește tehnica de interceptare și urmărire API este BoundsChecker de la Numega, un pachet profesional pentru detectarea erorilor în mediul Windows BoundsChecker vă permite să găsiți erori de API Windows, erori de interfață COM/OLE, erori de memorie, erori de indicator, scurgeri de resurse și blocări ale programului În special, BoundsChecker detectează apelurile de funcții eșuate, valorile nevalide ale parametrilor, funcțiile neimplementate, depășirile blocurilor de memorie, depășirile de stive, utilizarea memoriei neinițializate, matricea de indexare în afara limitelor, scurgerile de memorie, scurgerile de resurse etc Una dintre tehnicile de bază, utilizate în munca BoundsChecker este de a urmări apelurile către mii de funcții API Windows BoundsChecker interceptează apelurile de funcții API Windows pentru a verifica parametrii înainte de a apela funcții și pentru a stoca informații despre conținutul stivei, iar după apel pentru a verifica valoarea returnată înainte de a o transmite aplicației Când programul este lansat, sistemul BoundsChecker acționează ca un depanator, ceea ce vă permite să injectați DLL-ul acestui sistem în spațiul de adrese al procesului de aplicație și să transferați controlul către acestea Dacă BoundsChecker este integrat cu compilatorul, apelurile către DLL BoundsChecker sunt incluse direct în codul programului Într-un fel sau altul, toate apelurile la funcțiile API Win sunt preprocesate în BoundsChecker Microsoft System Journal publică frecvent articole despre utilizarea tehnicilor de snooping și snooping pentru a face roata mouse-ului să funcționeze, pentru a detecta operațiunile de memorie în programele COM sau pentru a găsi cauza blocajului în programele multithreaded Microsoft chiar include în Platform SDK și Windows Resource Kits un utilitar special de urmărire API numit top Capcanarea și snoopingul se realizează cel mai ușor în codul în modul utilizator, dar această posibilitate există și în codul în modul kernel Site-ul web www sysinternals com are mai multe utilitare care se bazează pe modificarea ierarhiei sistemului de fișiere în modul kernel Windows NT sau a lanțului de drivere de dispozitiv pentru a urmări accesul la sistem de fișiere, registry și porturi În Windows , chiar și Microsoft a recunoscut beneficiile deturnării driverelor de ecran, oferind suport pentru driverele de oglindire pentru driverele de ecran Probabil, Microsoft a primit în mod constant plângeri și întrebări de ce utilizatorul nu poate reproduce cu ușurință ecranul Windows pe un computer la distanță Acum, folosind driverul oglindă, puteți transfera fluxul de date prin rețea fără a interfera cu funcționarea driverului de ecran Este puțin probabil ca utilitățile comerciale, seturile de instrumente Microsoft și programele eșantion obținute din alte surse să vă satisfacă toate nevoile de urmărire și interceptare API - cel puțin dacă sunteți interesat de actualul Capitolul Monitorizarea sistemului grafic Windows un instrument remarcabil de convenabil, personalizabil, modular și destul de versatil Mai jos sunt enumerate doar câteva dintre limitările pe care le veți întâlni О Setarea tipurilor de date Instrumentele gata de fabricație funcționează cu un set limitat de tipuri de date, în timp ce în programarea Windows, tipurile de date sunt actualizate foarte frecvent Este de dorit ca utilitarul de urmărire să poată converti codurile operaționale binare bitmap în nume precum SCRCOPY, să salveze bitmap în fișiere sau, să zicem, să raporteze că un mâner GDI corespunde unui obiect stilou logic Oh Timing Capacitatea de a măsura timpul petrecut procesând un apel API Win va ajuta la optimizarea programului și la eliminarea apelurilor nedorite din acesta O Funcții API nedocumentate, apeluri intra-modul, apeluri de funcții de sistem, apeluri de cod în modul kernel Lipsa suportului pentru aceste caracteristici este unul dintre punctele slabe ale programelor standard Dacă doriți să pătrundeți cu adevărat în orice domeniu al programării Windows (cum ar fi programarea grafică), este aproape imposibil să faceți fără un program bun de monitorizare Construirea unui program de monitorizare Programul de monitorizare constă de obicei din două părți: un program de control și un cercetător (DLL sau driver) Programul de control trimite cercetașul la locul potrivit, îi dă comenzi și, eventual, primește informații Cercetașul pătrunde „în spatele” procesului utilizatorului, se fixează la locul potrivit, colectează cele mai mici informații din zona de interes, acționează în conformitate cu sarcina sau transmite informații programului de control Pe fig prezintă o diagramă a funcționării unui astfel de program Desigur, există multe variante ale acestui model general Dacă puteți găsi o modalitate fiabilă de a injecta un scout, astfel încât acesta să poată acționa singur, este posibil să nu aveți nevoie de un program de control De exemplu, unele medii de codificare a caracterelor pe doi octeți există „pe deasupra” unui sistem Windows obișnuit În loc să injecteze DLL-uri în toate aplicațiile GUI, ei pur și simplu redenumesc DLL-urile de sistem și le înlocuiesc cu propriile lor implementări pentru a suporta codificarea pe dublu octet pe un sistem cu un singur octet Dacă doriți să urmăriți operațiunile care au loc în spațiul de adrese în modul kernel, cel mai probabil veți avea nevoie de un driver de dispozitiv pentru modul kernel (adică DLL de recunoaștere) În acest caz, programul de control instalează driverul și gestionează funcționarea acestuia De exemplu, în programul Fosterer din Capitolul , driverul Periscope în modul kernel a fost folosit pentru a citi datele din spațiul de adrese kernel și apoi a analiza structurile de date grafice stocate în modul kernel SoftICE/W, depanatorul Numega la nivel de sistem, folosește, de asemenea, un driver în modul kernel pentru a oferi capabilități de depanare la nivelul întregului sistem pe o singură mașină Urmărirea apelurilor de funcție API Win Orez Monitorizarea componentelor programului La redactarea unui program de cercetași, este necesar să se rezolve mai multe probleme: Despre introducerea unui cercetaș în proces; О conexiune la lanțurile de apeluri ale funcției API; o primirea parametrilor, a valorilor returnate și a datelor de sincronizare; О salvarea datelor într-un format convenabil; o Crearea unei interfețe de utilizator pentru selectarea programelor și modulelor pe care doriți să le monitorizați, precum și a cârligelor API Win și a metodelor COM În această secțiune, vom crea un program Pogy pentru monitorizarea generală a apelurilor API Win Programul poartă numele unui submarin care a participat la cercetări științifice subacvatice Vom folosi Pogy pentru a explora profunzimile sistemului de operare Windows Interfața de utilizator a programului de control Pogy exe este concepută ca o casetă de dialog formată din mai multe pagini DLL Diver dll este responsabil pentru monitorizare Acum să aruncăm o privire rapidă asupra structurii acestui program Scout DLL Injection În Win API, este posibil să instalați cârlige la nivel de sistem sau la nivel de fir de program Interceptorii monitorizează mesajele sau modifică acțiunile standard întreprinse atunci când sunt procesate Cârligele sunt setate de funcția API SetWindowsHooksEx În Windows , numărul de clase de hook a crescut chiar la Să spunem, instalarea hook-ului de clasă WM GETMESSAGE monitorizează mesajele introduse în coada de mesaje, iar hook-ul de clasă WH SHELL primește notificări despre crearea și distrugerea ferestrelor de nivel superior Capitolul Monitorizarea sistemului grafic Windows Funcțiile interceptoare sunt de obicei implementate într-un DLL, ceea ce este o cerință pentru interceptorii la nivel de sistem Motivul este că, pentru ca interceptorul să funcționeze în alte procese, codul său trebuie să fie încărcat în spațiul de adrese al procesului țintă Un fișier executabil poate fi încărcat doar de un alt proces ca date, astfel încât interceptorul la nivel de sistem trebuie să fie implementat într-un DLL Odată ce DLL-ul este încărcat în spațiul de adresă al procesului, interceptorul poate face aproape orice dorește Unele tehnici de urmărire a apelurilor API se bazează pe acest fapt Cu toate acestea, trebuie să vă asigurați că DLL-ul ajunge în locul potrivit Funcția SetWindowsHookEx este doar una dintre modalitățile posibile de a injecta un DLL în procesul investigat Cu toate acestea, această metodă este simplă și bine documentată Pentru ca DLL să fie injectat în fiecare proces, acesta poate fi inclus în următoarea cheie de registry Windows NT/ : HKEY LOCAL MACHINE\Software\Microsoft\ Windows NTXVersiunea curentă\Windows\AppInit DLLs Cunoașterea modalităților non-triviale de a injecta DLL-uri în procesele externe este un bun indicator al abilităților de programare Windows Cartea clasică a lui Matt Pietrek, Windows System Programming Secrets, demonstrează cum să injectați un DLL prin API-ul de depanare Win și să modificați în mod dinamic codul procesului investigat Cartea lui Jeffrey Richter Programming Applications for Microsoft Windows (Ediția a -a) arată cum să faci același lucru folosind un fir de program de la distanță În programul nostru Pogy, funcția SetWindowsHookEx setează un cârlig la nivel de sistem, care este o funcție de indirectare definită de aplicație După înregistrarea în sistem, interceptorul la nivel de sistem este apelat atunci când apar anumite evenimente în sistem, în timp ce interceptorul la nivel de fir este responsabil pentru un singur fir Funcția de cârlig ShellProc este implementată în DLL-ul Diver dll, așa cum este cerut de cârligul la nivel de sistem Modulul Diver exportă funcția SetupDiver, care este apelată din programul de control Pogy exe pentru a efectua instalarea, dezinstalarea și configurarea interacțiunii dintre componente Mai jos este o parte a codului interceptor care funcționează pe partea DLL-ului scout #pragma data seg(„partajat”) HWND h Controller = NULL; HHOOK hJhellHook = NULL; #pragmadata seg() #pragma commentClinker ”/secțiune;Partajat, rws”) LRESULT CALLBACK ShellProc( int nCode WPARAM wParam LPARAM IParam ) { dacă (nCode==HSHELL WINDOWCREATED) dacă ( ) StartSpyO; assert(h ShellHook); Urmărirea apelurilor de funcție API Win dacă (h ShellHook) return CallNextHookEx(h ShellHoQfc, nCode, wParam IParam): el se returnează FALSE; } void declspec(dllexport) SetupDiverdnt nOpt HWND hWnd) { comutare (nOpt) { caz Diverjnstall: assert(h ShellHook==NULL); h ShellHook = SetWindowsHookEx(WH SHELL, (HOOKPROC) ShellProc, hlnstance ); h Controller = hWnd: break; case Diver UnInstall: assert(h Shel Hook!=NULL): UnhookWi ndowsHookEx(h Shel Hook); h ShellHook = NULL: pauză: } } Interceptorul la nivel de sistem este înregistrat în sistem (managerul de ferestre) o singură dată Funcția SetWindowsHookEx returnează un mâner care este utilizat de funcția de cârlig și care în cele din urmă îndepărtează cârligul apelând UnhookWindowsHookEx Apare problema: dacă cârligul la nivel de sistem poate fi încărcat în spațiile de adrese ale diferitelor procese, de obicei izolate unele de altele, atunci unde este stocat manipulatorul? Răspuns: în secțiunea de date generale a DLL-ului în care este definită funcția de interceptare Secțiunea obișnuită de date a unui fișier Win EXE este privată pentru procesul care a încărcat DLL; cu alte cuvinte, fiecare proces operează pe propria copie a acestei secțiuni Cu toate acestea, secțiunea de date partajate este partajată de toate procesele care au încărcat DLL-ul În fragmentul de mai sus, începutul și sfârșitul acestei secțiuni sunt marcate cu două directive de segment de date, iar directiva comment(linker) îi spune linkerului că această secțiune este citită/scrisă și partajată ("rws") Păstrăm interceptorul și mânerele ferestrelor într-o secțiune comună Vă rugăm să acordați atenție necesității de a inițializa datele secțiunii comune Programul de control Pogy exe este asociat cu același DLL Diver dll Când este încărcat, Pogy creează o fereastră pentru interacțiunea cu DLL-ul scout Pogy apelează apoi funcția SetupDiver(Diver Install, ), spunându-i cercetătorului mânerul ferestrei sale și permițându-i să creeze un cârlig Apelarea funcției SetWindowsHookEx returnează mânerul cârlig necesar pentru a invoca următorul cârlig din lanțul de cârlig Daemonul și mânerele ferestrei hook sunt stocate în DLL și sunt, prin urmare, disponibile pentru toate procesele utilizatorului Astfel, după atribuirea h ShellHook și h Controller, orice proces poate accesa aceste variabile Capitolul Monitorizarea sistemului grafic Windows Cu toate acestea, până în acest moment biblioteca Diver dll a fost încărcată doar în procesul programului de control Funcția de cârlig este apelată numai atunci când fereastra de nivel superior este creată sau distrusă Dacă acest lucru se întâmplă într-un alt proces decât procesul demonului, sistemul de operare vede că interceptorul apelat nu este prezent în procesul curent și încarcă DLL-ul cu interceptor După ce DLL-ul este încărcat, funcția ShellProc este apelată cu codul HSHELL-WINDOWCREATED Funcția ShellProc contactează demonul și determină dacă să înceapă urmărirea apelurilor API Principalul lucru pe care sistemul de operare îl cere de la funcția de cârlig este că își amintește să apeleze următorul cârlig din lanț cu funcția CallNextHookEx Funcția SetupDiver oferă și posibilitatea de a dezactiva interceptorul Conectarea la lanțul de apeluri al funcției API După ce a primit o comandă de a începe lucrul din programul de control, DLL-ul scout este inițializat și creează o fereastră ascunsă Mânerul acestei ferestre este transmis programului de control Din acest moment, programul de control și cercetașul pot schimba mesaje prin mânerele ferestrei Pe sistemul de operare Windows, mesageria simplă cu doi parametri pe de biți utilizează coduri de mesaje utilizator care încep cu prefixul WM USER Dar dacă doriți să treceți un bloc de date din limitele procesului, un pointer obișnuit nu va funcționa - un pointer care aparține unui spațiu de adrese, în general, nu funcționează într-un alt spațiu de adrese Din fericire, puteți folosi funcția WM COPYDATA pentru a trimite blocuri de date Sistemul de operare Windows asigură în mod specific că blocurile de date din mesajele WM SETTEXT, WM GETTEXT și WM COPYDATA sunt copiate corect de-a lungul granițelor procesului După ce a primit informații că DLL-scout a creat o fereastră de comunicare, programul de control trimite o listă de funcții monitorizate Fiecare funcție primește numele modulului apelant, numele modulului apelat, numele funcției, numărul de parametri, tipurile de parametri și tipul de returnare De exemplu, dacă utilizatorul dorește să monitorizeze apelurile către funcția GDI SetTextColor din programul CLOCK EXE, sunt setate următoarele valori: Numele modulului de apelare este CLOCK EXE; Numele modulului apelat este GDI DLL; Numele funcției este SetTextColor; О numărul de parametri este doi; О tipuri de parametri - HDC și COLORREF; Tipul de returnare este COLORREF Pe baza datelor primite, DLL construiește un tabel intern de module și funcții monitorizate Capitolul a analizat pe scurt formatul de fișier PE folosit pentru a reprezenta modulele Win (atât pe disc, cât și în memorie) S-a menționat că la legarea modulelor static sau dinamic se folosesc directoare de export și import, cu adresa fiecărui import stocată Urmărirea apelurilor de funcție API Win funcția să fie transpusă într-o variabilă internă Prin urmare, pentru a vă conecta la lanțul de apeluri al funcției API Win , trebuie doar să găsiți în directorul de import al modulului adresa unde este stocată adresa funcției importate și să o înlocuiți cu adresa funcției de interceptor Desigur, pentru ca programul să funcționeze corect, adresa inițială trebuie salvată înainte de a fi înlocuită Când monitorizați mai multe funcții simultan, nu puteți înlocui pur și simplu mai multe adrese importate cu o singură adresă a funcției de cârlig Funcția de interceptor trebuie cel puțin să știe pentru ce funcție monitorizată este numită În implementarea noastră, pentru fiecare element al tabelului de funcții urmărite, este creată o mică funcție stub care împinge indexul funcției pe stivă înainte de a apela funcția generică ProxyProlog Astfel, la modificarea directorului de import al unui modul, sunt folosite adrese stub Stub-urile arată astfel: push Index // xx xx xx xx jmp ProxyProlog // E aa aa aa aa Funcția ProxyProlog trebuie doar să scoată indexul din stivă și apoi să-l folosească atunci când accesează tabelul de funcții pentru a obține informațiile complete Pe fig Figura - arată cum este apelată funcția Win înainte și după ce directorul de import este modificat de adresa stub Partea stângă arată situația înainte de interceptare; valoarea variabilei directorului de import este folosită pentru a apela indirect funcția API Win Partea dreaptă arată ce se întâmplă după modificare Aplicația efectuează acum un apel indirect către stub care transmite controlul funcției generice ProxyProlog Diver dll Funcția ProxyProlog și funcțiile și structurile de date însoțitoare Diver dll sunt responsabile pentru a se asigura că, după procesare, funcția originală Win API este apelată și apoi controlul este returnat apelantului Aplicație Aplicație Orez Interceptarea apelurilor de funcție API folosind un stub Capitolul Monitorizarea sistemului grafic Windows NOTĂ - Pentru ca soluția să fie cât mai universală, ar trebui să evitați modificarea conținutului registrelor Dacă indexul nu ar fi trecut pe stivă, ci într-un registru, soluția noastră nu ar funcționa pentru funcțiile care folosesc registre pentru a transmite parametri Colectarea de informații Pentru funcțiile pe care le monitorizăm, apelul la ProxyProlog precede apelul la funcția API Win reală Cu toate acestea, ProxyProlog și funcțiile sale aferente au o treabă foarte dificilă - colectează informații despre toți parametrii, salvează timpul de intrare în funcție, apelează funcția API originală, salvează timpul de întoarcere din funcție, salvează valoarea returnată și în cele din urmă returnați controlul apelantului Programul scout trebuie să restabilească tot ceea ce a atins la forma sa anterioară - toate registrele și steagurile procesorului (cu excepția contorului de ceas) Datorită complexității sale, această sarcină este împărțită între mai multe funcții scrise în asamblare, C și chiar C++ folosind funcții virtuale A Funcția ProxyProlog este scrisă în asamblator simplu, în sensul că compilatorul nu trebuie să includă codul standard de intrare și ieșire a funcției în ea Funcția salvează conținutul registrelor, ora curentă (ora ), apelează funcția ProxyEntry, salvează din nou timpul (timpul ), restabilește registrele și, în final, readuce controlul la funcția API Win inițială apelată de aplicație A Funcția ProxyEntry este scrisă în C Creează o structură KRoutinelnfo pe stiva de programe, stochează informații de bază despre apel, apelează funcția virtuală C++ KFuncTable: - FuncEntryCallBack, modifică stiva procesorului astfel încât atunci când funcția API Win originală iese , controlul este mai întâi transferat la funcția ProxyEpilog și apoi modifică din nou stiva procesorului, astfel încât funcția ProxyProlog să transfere controlul către funcția API Win originală A Funcția KFuncTable::FuncEntryCallBack este implementată ca funcție virtuală C++ Într-o implementare minimă, nu face nimic Cu toate acestea, această funcție are toate informațiile despre parametri și timpii de intrare-ieșire, așa că, dacă se dorește, poate efectua cronometrare, salva parametri, verifica și chiar modifica valorile acestora A Funcția ProxyEpilog, scrisă în asamblare goală, este apelată imediat după revenirea din funcția API Win Salvează registrele, salvează timpul (timpul ), apelează funcția ProxyExit, salvează din nou timpul (timpul ), restabilește registrele și, în final, readuce controlul apelantului, completând astfel monitorizarea unui apel către funcția API A Funcția ProxyExit este scrisă în C Ea scoate o structură KRoutinelnfo din stiva de programe, apelează funcția virtuală KFuncTable: :Func-ExitCallBack și modifică stiva procesorului astfel încât funcția ProxyEpilog să revină la apelantul original Urmărirea apelurilor de funcție API Win A Funcția KFuncTable: :FuncExitCallBack este implementată ca funcție virtuală C++ Într-o implementare minimă, nu face nimic Funcția are toate datele despre orele de intrare și ieșire, precum și valoarea de returnare a funcției API Dacă este necesar, poate returna aceste informații programului de control Mai jos este codul pentru cele mai importante funcții de intrare, ProxyProlog și ProxyEntry typedef struct { m flag nesemnat; nesemnat m edx; nesemnat m ecx; m ebx nesemnat; nesemnat m eax; nesemnat m funcid; m rtnads nesemnate; nesemnat m para[ ]: } EntryInfo; declspec(gol) void ProxyProlog(void) { // funcid rtadr, pl pn // funcid își rezervă spațiu pe stivă // care este completat ulterior cu adresa persoanei care apelează // Păstrează registrele și steagurile comune asm push eax asm push ebx asm push ecx asm push edx // edx ecx ebx eax asm pushfd // octeți EFLAGS asm emit OxOF // Ora asm emit x asm shrd eax edx // EAX = EDX:EAX » asm push eax // Ora de intrare asm sub eax, OverHead asm push eax // Timp de intrare - cost asm lea eax [esp+ ] // Flag offset pe stivă asm push eax asm caii ProxyEntry // Funcția C asm pop ecx // ecx = timpul de conectare asm emit OxOF // Ora asm emit x asm shrd eax edx // EAX = EDX:EAX " asm sub eax ecx // Costuri noi după ProxyEntry asm add OverHead eax // Restaurează registrele și steaguri comune asm popfd Capitolul Monitorizarea sistemului grafic Windows asm pop edx asm pop ecx asm pop ebx asm pop eax // Reveniți controlul apelantului asm ret } void stdcall ProxyEntry (EntryInfo * nfo, unsigned entertime) { int id = info->m funcid: assert(pStack!=NULL): KRoutineInfo * rutina = pStack->Push(); dacă (de rutină) { rutina->entertime = entertime; routine->funcid = id: routine->rtnaddr « info->m rtnads: pFuncTable->FuncEntryCallBack(rutine info): // Modificați adresa de retur astfel încât înainte de a reveni // controlul a fost transferat apelantului inițial // funcția noastră ProxyEpilog info->m rtnads "(nesemnat) ProxyEpilog: } // Oferă controlul de întoarcere la funcția originală // la ieșirea din ProxyProlog info->m funcid - (nesemnat) pFuncTable->m func[id] f olddress: } Măsurarea timpului este realizată în cel mai precis și eficient mod disponibil pe procesoarele Intel datorită instrucțiunii RDTSC Această instrucțiune revine în EDX:EAX înregistrează numărul de de biți de cicluri de procesor de la ultima pornire Pe un procesor Pentium de MHz, un ciclu de ceas durează ns Lucrul cu valori pe de biți este incomod, așa că programul mută perechea EDX:EAX cu biți la dreapta și folosește doar valoarea inferioară de de biți Intervalul de timp minim crește la x în ns, ceea ce este încă mult mai bun decât precizia în milisecunde oferită de funcția GetTickCount Cu o precizie de , µs, o valoare de de biți poate reprezenta un interval de până la , ore; pentru testarea normală, acest lucru este suficient Pentru un apel API, programul citește contorul ceasului de ori: înainte de a apela ProxyEntry, înainte de a apela funcția API conectată, înainte de a apela ProxyExit și înainte de a returna controlul apelantului Intervalul dintre punctele și determină aproximativ costul intrării în funcție; intervalul dintre punctele și determină costul real al apelării funcției Win API; în sfârșit, intervalul dintre punctele și determină costul ieșirii Urmărirea apelurilor de funcție API Win funcții Programul menține o variabilă globală, OverHead, care însumează toate cheltuielile generale și își scade valoarea din datele de sincronizare Stiva folosită pentru a trece parametrii și adresa de retur crește către adrese inferioare; atunci când o nouă valoare este stocată, indicatorul stivei este decrementat, iar când o nouă valoare este preluată, aceasta este incrementată Blocul de parametri este urmat de adresa de retur Când este apelată, funcția stub împinge identificatorul funcției (index) în stivă și apoi apelează ProxyProlog Funcția ProxyProlog împinge unele registre standard și o copie a registrului steagurilor procesorului în stivă Toate aceste valori se mapează la o structură EntryInfo de nivel C, căreia i se trece un pointer ProxyEntry Funcția ProxyEntry folosește un pointer către EntryInfo pentru a obține ID-ul funcției și pentru a modifica adresele de returnare din stivă Cel mai interesant lucru se întâmplă în continuare După apelarea ProxyEntry, funcția ProxyProlog restabilește registrele generale și registrul flag și apoi execută instrucțiunea ret Unde revine controlul? Înainte exista un index al funcției stub în partea de sus a stivei procesorului, dar mai târziu funcția ProxyEntry scrie adresa funcției originale Win API în acest loc Prin urmare, ultima instrucțiune ret din ProxyProlog returnează de fapt controlul implementării originale API De exemplu, dacă pășim în lanțul de cârlig al funcției GDI DeleteObject, codul stub împinge indexul funcției (de exemplu, ) în stivă și apelează ProxyProlog Funcția ProxyProlog apelează funcția ProxyEntry pentru a salva parametrii și a înlocui indexul cu adresa implementării GDI a DeleteObject Astfel, ultima instrucțiune ProxyProlog transferă controlul către funcția GDI DeleteObject Partea de ieșire este o imagine în oglindă a părții de intrare Funcțiile ProxyEpilog și ProxyExit sunt enumerate mai jos pentru a fi complet typedef struct { nesemnat m rslt; } ExitInfo; declspec(gol) void ProxyEpilog(void) { asm push eax // Rezultatul apelului API // Rezervă, de asemenea, spațiu // pentru adresa de retur asm push eax // Păstrați registre partajate asm push ebx asm push ecx asm push edx asm pushfd // octeți de steaguri asm emit OxOF // Ora asm -emit x asm shrd eax, edx, // EAX "EDX:EAX" asm push eax // Timp de ieșire asm sub eax, OverHead Capitolul Monitorizarea sistemului grafic Windows asm push eax // Timp de ieșire - cost asm lea eax, [esp+ ] // Adresa zonei rezervate asm push eax asm caii ProxyExit asm pop ecx // ecx = timpul de iesire asm emit OxOF // Ora asm emit x asm shrd eax, edx // EAX = EDX: EAX » asm sub eax ecx // Costuri noi după ProxyEpilog asm add OverHead eax asm popfd // Restaurează steaguri și registre asm pop edx asm pop ecx asm pop ebx asm pop eax asm ret // returnează controlul } // apelantul original void stdcall ProxyExit(ExitInfo *informații, concediu nesemnat) { int adâncime; assert(pStack); KRoutineInfo * rutina = pStack->Lookup(adâncime); dacă (de rutină) { pFuncTable->FuncExitCallBack(rutină, informații, concediu, adâncime): info->m rslt = rutina->rtnaddr: pStack->Pop(); } } Când o funcție API Win conectată iese, controlul nu revine direct apelantului În schimb, funcția noastră ProxyEpilog este numită Acest lucru se datorează faptului că funcția ProxyProlog schimbă adresa de retur de pe stivă pentru a indica ProxyEpilog (printr-o simplă atribuire info->m rtnads = (nesemnat)ProxyEpilog) Am stocat cu înțelepciune această adresă de retur pe stiva de software pentru o utilizare ulterioară Acum o atenție deosebită se acordă registrului EAX; deține valoarea de returnare scalară a funcției (de exemplu, mânerul GDI returnat de funcția CreateSolidPen) Funcția ProxyEpilog îl salvează pe stivă și transmite informațiile către ProxyExit ca indicator către o structură ExitInfo Structura ExitInfo constă dintr-un singur câmp care stochează valoarea returnată a funcției Funcția ProxyExit localizează structura KRoutinelnfo pe stiva de programe, apelează funcția KFuncTable: :FuncExitCallback și apoi împinge returnarea Urmărirea apelurilor de funcție API Win A-a valoare de pe stivă este adresa de retur care este utilizată de funcția ProxyEpilog pentru a transfera controlul către apelantul inițial prin intermediul funcției ret Pe fig Figura prezintă procesul de interceptare a funcției API împreună cu toate modificările care apar în stiva procesorului Partea de jos arată transferul de control de la aplicație la stub, funcțiile ProxyProlog, funcțiile Win API, ProxyEpilog și înapoi la aplicație (funcțiile ProxyProlog și ProxyEpilog sunt auxiliare) Partea de sus a figurii arată modificările din stiva Grămadă Orez Transfer de control și modificări în stiva la interceptarea funcțiilor API Și ultimul lucru de menționat este designul stivei de software Pentru fiecare apel de funcție API, programul trebuie să creeze o structură KRoutinelInfo cu informații despre apelul de funcție, utilizate atât de părțile de intrare cât și de ieșire Când este apelată o funcție API, o nouă structură este împinsă în stivă, iar când apelul API este finalizat, ultima intrare este scoasă din stivă Totul este în regulă cu excepția cazului în care procesul constă din mai multe fire de execuție de program Luați în considerare următoarea situație: primul fir apelează funcția API și blochează așteptarea unei resurse; apoi al doilea thread apelează funcția API și, de asemenea, blochează Acum primul thread „se trezește” și termină procesarea funcției API În acest caz, stiva de software nu mai urmează principiul LIFO (last in, first out) Acest principiu este într-adevăr respectat doar la nivelul fluxului de programe Rețineți că stiva de procesoare utilizată în procesarea apelurilor API Win este pe deplin compatibilă cu LIFO, deoarece fiecare fir de execuție de program funcționează pe o stivă separată În implementarea stivei noastre de software, problema este rezolvată prin etichetarea fiecărei structuri cu un ID Capitolul Monitorizarea sistemului grafic Windows firul curent, iar împingerea și ieșirea din stiva de software trebuie să fie coordonate la nivel de fir O secțiune critică este utilizată pentru a proteja stiva de modificări Ieșire de date Deci, funcțiile pe care le-am luat în considerare colectează tot felul de informații despre apelurile de funcții API Convertirea datelor „brute” într-o formă mai semnificativă și mai utilizabilă este, de asemenea, una dintre sarcinile cercetătorului DLL Desigur, datele pot fi salvate în multe formate diferite, dar formatul text simplu este cel mai ușor de generat și citit Probabil, este mai convenabil să procesezi volume mari de date acumulate în foi de calcul sau baze de date Programe precum Microsoft Excel, Lotus sau Microsoft Access convertesc cu ușurință fișierele text formatate corespunzător în formatul lor de lucru Tot ceea ce vă este necesar este să oferiți o separare consecventă a coloanelor în fișierele text, fie printr-o lățime fixă, fie folosind caractere de tabulatură, două puncte, virgule și alte caractere de serviciu De exemplu, programul SysCall din Capitolul generează liste de funcții de sistem GDI apelate din GDI DLL Cu toate acestea, lista este ordonată în funcție de ordinea numelor simbolice din fișierele de depanare, nu în funcție de identificatorii funcției de sistem sau de adresele apelantului Puteți crea un tabel în Microsoft Excel, puteți importa un fișier text generat de SysCall în el cu separare a coloanelor cu lățime fixă și apoi personalizați lățimile și tipurile coloanelor Rezultatul este o foaie de calcul Excel cu instrumente ușoare de sortare și analiză a datelor DLL-ul nostru de recunoaștere scoate date într-un fișier text, separând câmpurile cu virgule Fișierele sunt denumite secvențial pogyOOOO txt, pogy txt și așa mai departe Codul de creare a fișierului găsește următorul număr liber din secvență pentru a preveni ștergerea fișierelor vechi În cel mai simplu caz, ieșirea datelor este organizată simplu Parametrii funcției Win API au de obicei octeți; valoarea returnată a funcției scalare trecută în registrul EAX are aceeași dimensiune Cea mai proastă soluție este să scoți toate valorile ca cifre hexazecimale Astfel, TRUE va fi scos ca „ x ”, FALSE ca „ x ”, codul de operare bitmap SRCC PY ca „ x CC ”, iar pentru un șir de text va fi scos doar adresa În general, pentru un hacker va funcționa, dar pentru utilizatorii obișnuiți este foarte incomod API-ul Win definește o gamă foarte bogată de tipuri (sau cel puțin macrocomenzi de tip) Lucrăm cu numere semnate și nesemnate de diferite dimensiuni, pointeri de toate felurile, nenumărate manipulatoare și tipuri de nivel înalt precum BITMAPINFO, LOGFONT, DEVMODE etc Arhitectura DLL scout vă permite să alegeți o interpretare specifică pentru fiecare dintre aceste tipuri Pentru fiecare funcție API Win , tipurile de parametri și valorile returnate pot fi specificate și după nume Valorile de același tip sunt interpretate în același mod poti personaliza Urmărirea apelurilor de funcție API Win procesul de conversie a datelor brute în format text și adăugarea de suport pentru noi tipuri de date folosind DLL-uri plug-in Pentru a facilita lucrul cu sute de nume de tip, funcții și module, vom folosi un tabel atom și vom converti numele din format text în indici întregi De exemplu, în loc de numele COLORREF, programul trece atomul întreg COLORREF, a cărui valoare se obține în etapa de inițializare când șirul COLORREF este inclus în tabelul atom Toate componentele sistemului funcționează cu aceeași tabelă atom, așa că dacă o altă componentă dorește brusc să reincludă COLORREF în tabelul atom, reincluderea nu va avea loc; în schimb, valoarea întreagă inițială va fi returnată Acesta este foarte asemănător cu API-ul atomic din Win Programul implementează tabelul de atomi fără a utiliza funcțiile atomice Win API din motive de viteză și portabilitate Tabelul atom este convertit în clasa de bază C++ lAtomTable, care este foarte asemănătoare cu interfața COM (cu toate acestea, în acest caz, nu avem nevoie de interfața IUnknown): struct lAtomTable { virtual ATOM AddAtom(const char * nume) = ; virtual const char * GetAtomName(ATOM atom) = ; }' Împreună cu tabelul de atomi, este definită și o clasă de bază C++ IDcoder care convertește unele tipuri de date în format text: struct IDcoder { virtual bool Inițialize(lAtomTable * pAtomTable) = : virtual int Decode(ATOM typ const void * pValue, char * szBuffer int nBufferSize) = ; }; În această declarație, cuvântul cheie struct este echivalent cu class, cu excepția faptului că toate tipurile și funcțiile care sunt definite sunt publice Cuvântul cheie al interfeței COM este definit ca o structură în basetypes h Metoda IDecoder::Initialize include numele tipurilor de date din tabelul atom Metoda IDecoder::Decode decodifică un bloc de date într-un buffer de text și returnează dimensiunea datelor implicate Această arhitectură vă permite să lucrați cu blocuri de date în loc de valori individuale de octeți, ceea ce este foarte convenabil atunci când decodați parametrii care nu pot fi decodați individual în mod semnificativ De exemplu, pentru funcția ExtTextOut, ultimii doi parametri sunt numărul de caractere și un indicator către un tablou întreg Fără a cunoaște numărul de caractere, decodorul nu va putea determina câte elemente din matrice ar trebui să decodeze Dacă clasa IDecoder este definită așa cum se arată mai sus, puteți defini un nou tip de matrice, CountedIntArray și puteți transmite două valori de de biți pentru această matrice metodei IDecoder::Decode Metoda IDecoder:- Decode returnează numărul de octeți implicați sau dacă nu au fost procesate date Capitolul Monitorizarea sistemului grafic Windows DLL-ul scout conține un decodor de bază (clasa KBasicDecoder) pentru a decoda cu ușurință tipurile de date standard Win Mai jos este un mic fragment din această clasă ATOM atom char: ATOM atom BYTE; ATOM atom COLORREF; bool KBasicDecoder::Ini ti alize(lAtomTable * pAtomTable) { Dacă ( pAtomTable==NULL ) returnează fals: atom char = pAtomTable->AddAtom("char"): atom BYTE = pAtomTable->AddAtoml("BYTE,,): atom COLORREF = pAtomTable->AddAtom("COLORREF"): returnează adevărat: } int KBasicDecoder::Decode(ATOM typ, const void * pValue char * szBuffer, Int nBufferSize) { date nesemnate = * (nesemnat *) pValue: if ( typ==atom char ) { wsprintf(szBuffer, "'Xc"', date): întoarcere : } if ( typ==atom BYTE ) { wsprintf(szBuffer, 'W, date & OxFF); întoarcere ; } if ( typ==atom COLORREF ) { dacă (date== ) strcpy(szBuffer, „NEGRU”): el se if ( data==OxFFFFFF ) strcpy(szBuffer, „ALB”): el se wsprintf(szBuffer, „X x”, date): întoarcere ; } returnează : // Tipuri brute } În timpul etapei de inițializare, DLL scout creează un tabel de atomi, inițializează instanța KBasicDecoder, încarcă un fișier ini cu informații despre setările speciale IDecoder, încarcă și inițializează fiecare dintre ele Urmărirea apelurilor de funcție \L/ip API Funcția statică MainDecoder gestionează întregul proces de decodare a unui bloc de date Trece prin lanțul de implementări IDecoder și găsește unul care vă permite să decodați anumite tipuri de date Implementările KFuncTable::FuncEntryCallBack și KFuncTable::FuncExitCal Back apelează pur și simplu MainDecoder Deci, avem un decodor extensibil pentru decodarea tipurilor de date Win După cum puteți vedea, familiaritatea cu arhitectura extensiei de depanare WinDbg ne-a învățat ceva Program de control Am descoperit procesul de introducere a unui DLL-scout, de interceptare a funcțiilor Win API, de colectare a informațiilor și de ieșire a datelor Ce altceva lipsește din soluția noastră? Evident, programul de control, cu ajutorul căruia sunt selectate programele atacate, modulele și funcțiile monitorizate, precum și definiția exactă a API-ului Win Configurația demonului Pogy este definită de mai multe fișiere IP standard Windows Aceste fișiere sunt stocate într-un format text, structura lor se explică de la sine, iar API-ul Win oferă instrumente pentru procesarea lor Daemonul este o aplicație Win , așa că nimic nu ne împiedică să folosim toate caracteristicile Win disponibile Fișierul de date principal, Pogy ini, este format din două secțiuni Secțiunea Țintă listează aplicațiile pe care doriți să le monitorizați, împreună cu fișierele de configurare pentru fiecare aplicație Secțiunea Opțiune stochează parametrii generali de funcționare a programului (de exemplu, steagurile pentru înregistrarea apelurilor API și afișarea informațiilor despre apeluri într-o fereastră) DLL-urile pentru decodarea unor tipuri de date suplimentare sunt, de asemenea, indicate aici Exemplu de fișier Pogy ini: [Ţintă] KL CK EXE (pclock ini) =NOTEPAD EXE (pnotepad ini) [Notepad] LogCall=l Apelare=O Decoderl=pogygdi dl ! Create GDI Decoder@ Decoder =pogygdi dl ! Create DDRAW Decoder Conform acestui fișier ini, dorim să înregistrăm apelurile API, dar fără a afișa informații despre ele Două decodoare sunt conectate la program pentru tipuri de date suplimentare: unul este pentru tipurile GDI, iar celălalt este pentru tipurile legate de DirectDraw Utilizatorul poate monitoriza activitatea unuia dintre cele două programe, fiecare dintre ele având un fișier ip separat Fișierul ini la nivel de aplicație listează modulele procesului de aplicație pe care urmează să le monitorizați Utilizatorul trebuie să specifice numele modulului apelant, numele modulului apelat și numele fișierului ini pentru grupul de funcții API Exemplu: [Modul] CLOCK EXE Gd DLL, wingdi CLOCK EXE User DLL, Winuser Capitolul Monitorizarea sistemului grafic Windows Aceasta înseamnă că suntem interesați de apeluri către GDI DLL și USER DLL; au fișiere ip separate wingdi ini și winuser ini Rețineți că fișierele ini ale grupului de funcții API joacă același rol în programul nostru ca fișierele de antet Windows într-un compilator C/C++; cu alte cuvinte, ele conțin descrierea API utilizată de program în timpul monitorizării Desigur, mi-ar plăcea să inventez o modalitate automată de a construi aceste fișiere ini din conținutul fișierelor antet Windows, fișierelor bibliotecă sau unele fișiere cu nume simbolice Dar, deocamdată, să nu ne distram atenția și să introducem manual toate informațiile - numele modulului, numele funcției, lista de tipuri de parametri și tipul de returnare Mai jos este un mic fragment al fișierului pentru API-ul GDI [wingdi] Int SelecteiIpRgnCHDC HRGN) int SetROP (HDC nt) BOOL SetWindowExtEx(HDC int int, LPSIZE) BOOL SetBrushOrgEx(HDC int int LPPOINT) BOOL LPtoDP(HDC, LPPPOINT int) HBRUSH CreateBrushIndirect(LPLOGBRUSH) HBRUSH CreateDIBPatternBrushPt(LPVOID UINT) BOOL DeleteDC(HDC) HBITMAP CreateBitmap(int int UINT UINT LPVOID) HDC CreateCompatibleDC(HDC) HBRUSH CreateSolidBrush(COLORREF) HRGN CreateRectRgnIndirect(LPRECT) INT SetBoundsRect(HDC LPRECT UINT) BOOL PatBlt(HDC int int int int DWORD) BOOL SetViewportOrgEx(HDC int int LPPOINT) BOOL SetWindowOrgEx(HDC int int LPPOINT) int SetMapMode(HDC int) Interfața de utilizator a programului de control Pogy este o casetă de dialog formată din trei pagini cu file Pagina Evenimente înregistrează evenimente precum crearea și distrugerea ferestrelor, interceptarea apelurilor de funcții API de către cercetătorul DLL și afișează informații detaliate despre apelurile API (dacă este setat indicatorul corespunzător în fișierul ini) Pagina Configurare setează steagurile de înregistrare a datelor Pagina API afișează datele citite de program din fișierele ini Aici puteți selecta și aplicația pe care urmează să o monitorizați (dintre cele enumerate în Pogy ini) Tabelul afișează informații despre descrierile funcțiilor API încărcate Pagina API a programului de control este prezentată în fig Odată lansat, Pogy instalează un interceptor la nivel de sistem implementat în Diver dll Când o fereastră de nivel superior a oricărei aplicații este creată sau distrusă, DLL-ul scout este încărcat în spațiul său de adrese Diver dll primește numele executabilului principal al aplicației și trimite un mesaj către Pogy pentru a vedea dacă procesul ar trebui monitorizat Dacă comanda este dată, DLL-ul scout creează o fereastră ascunsă pentru a primi informații despre funcțiile monitorizate, se alătură lanțului de interceptare a funcțiilor specificate și începe să scrie informațiile primite într-un fișier text Monitorizarea se oprește când aplicația țintă se termină Urmărirea apelurilor de funcție API Win și CLOCK EXE Qa"; II Gdi dll II Gdi dll iHGdi dll ;^Gdi dll II Gdi dll dacă|Gdi dll £jGdi dll i^Gdi dll ilBGdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll Gdi dll AddFontR esoutceA AddFontResourceW AnimatePalette Arc BitBIt CancelDC Chord ChoosePixelFormat CloseMetaFile CombineRgn Orez Interfața utilizator Win API Monitor După toate eforturile depuse, ne așteaptă o recompensă - protocolul de apelare a funcției API Win generat de cercetătorul DLL sub controlul programului principal Pe fig Figura prezintă unul dintre aceste fișiere importate în Microsoft Excel întoarcere Adâncime: Introduceți ' Y ' bb' ,' ,' părăsi I , , , ADEVĂRAT ADEVĂRAT ADEVĂRAT b a І a І ADEVĂRAT ADEVĂRAT apelant CL CkEXE+ bd CEAS EXE+ CL Ck EXE+ bd Sidsk EXE+І І ' CEAS EXE+ b CEAS EXE+ ' CEAS YOHYO+ CEAS YOHYO+ Y Cl ck EXE+ bd CLOCK EXE+ sС skЁХЁ + b' CLOCK EXE+ : CLOCK EXE+ a ;'Gdi dll!GetfextExtentExPointwjl Calee Gdi dîiîSet BkMode '" ' i Gdi dllDeleteObject Sdi dll!ȘețBkMqde i Gdi dllDeiete bject j Gdi dlHCreateFontlndirecțW j Gdi dli!SelectObject : Gdi dll^etTextExtentPointW : ,Gdi ^ [Gdi dll! Seiectdbject Gdi dll!pelețeO^ i Gdi diiiCreateFontîndirectW i Gdi diliSelectObject Parametrul Т j de Î l'i de î LdGFONTW*( a ctf I I b I І І ■ b a rLbGFdNTW*(i a cb^ Y Orez Protocolul de apel API importat în Excel Pentru fiecare apel la funcția API corespunzătoare unei linii din fig , este indicat nivelul de cuibărit (până acum - doar ), ora de intrare și ieșire din Capitolul Monitorizarea sistemului grafic Windows funcția, valoarea returnată, adresa apelantului și numele funcției care trebuie apelată și orice parametri trecuți Unele date sunt afișate în formă zecimală, unele date sunt afișate în sistem hexazecimal, iar unele date sunt afișate sub formă de simboluri mnemonice Până acum, programul nostru de cercetători este programat doar pentru a înregistra apeluri API Puteți adăuga cod la acesta care ar oferi verificarea parametrilor, verificarea rezultatului apelului și chiar detectarea scurgerilor de memorie/resurse Pentru a verifica parametrii, trebuie să cunoașteți intervalul de valori valide pentru fiecare parametru De exemplu, funcția SelectObject selectează un mâner de obiect GDI valid în contextul dispozitivului, fie mânerul implicit, fie unul creat de procesul curent Încercarea de a selecta un mâner GDI nevalid sau un mâner care aparține altui proces este un semnal roșu (în special pe Windows NT/ ) Rezultatul unei funcții este verificat în același mod De exemplu, dacă funcția SelectObject returnează un handle GDI valid, acesta este un indiciu al unei erori la excluderea obiectului GDI din context, o posibilă cauză a scurgerii obiectelor GDI Cu toate acestea, detectarea scurgerilor de obiecte GDI este mai dificilă Va trebui să înregistrați toate apelurile la funcțiile care creează obiecte, împreună cu valoarea manipulatorului și adresa apelantului Când un obiect GDI este șters (folosind funcția DeleteObject), mânerul său este exclus din lista de mânere salvate Când programul se termină, manipulatorii care rămân în lista dvs aparțin obiectelor GDI „pierdute”; programul ar trebui să afișeze informații exacte despre creatorii lor Ca de obicei, fișierele de depanare a numelor simbolice vă vor ajuta să convertiți adresele în nume mai semnificative Urmărirea apelurilor Win GDI În orice domeniu al programării Windows, regula generală este că a face o treabă este ușor, dar a o face cu brio este greu Desigur, programul nostru de monitorizare Win API aduce beneficii reale, dar lasă mult de dorit Pentru a atinge obiectivul principal - înțelegerea tuturor aspectelor muncii GDI - trebuie încă să muncim din greu De fapt, dorim să orientăm programul pentru a monitoriza funcțiile GDI și DirectDraw, care, de fapt, face obiectul acestei cărți Acest lucru ne va permite să folosim funcțiile Win API implementate în KERNEL DLL și USER DLL fără să ne îngrijorăm că ar putea fi monitorizate GDI API Definition File În primul rând, avem nevoie de un fișier ini complet sau aproape complet, care poate fi citit de DLL-scout și care descrie cât mai multe funcții API GDI posibil Urmărirea apelurilor Win GDI Toate informațiile necesare sunt prezente în fișierele antet Windows, împreună cu informații care nu ne interesează deloc Desigur, ne-am dori să avem mijloace automate pentru a extrage prototipurile de funcții principale din fișierele antet și a le aduce într-un format simplificat Un parser de fișiere antet C simplu, dar specializat, este un subiect bun de lucru pentru studenții de la construirea compilatorului Rezultatul este un mic program de consolă Windows, Skim-mer, care caută în fișiere macrocomenzi cheie, cum ar fi WINGDIAPI, WINUSERAPI, WINAPI și APIENTRY, caracteristici standard de prototip al funcției API Win După ce s-a asigurat că prototipul actual al funcției este găsit, programul elimină excesele precum CONST, FAR, IN și OUT, precum și numele parametrilor Tot ce rămâne este o definiție concisă a funcției Win API Funcțiile documentate exportate de modulul GDI DLL sunt definite în trei fișiere antet Windows DDK: inc\wingdi h (funcții GDI standard), inc\winddi h (funcții DDI în modul utilizator) și sec\print\genprint \winppi h (funcții GDI pentru a sprijini motorul de imprimare EMF) Doar fișierul include\wingdi h este inclus în distribuția Visual C++ După ce am procesat aceste trei fișiere antet cu programul Skimmer, avem trei fișiere ini care sunt aproape gata de utilizare de către programul Pogy Singura excepție este caracteristica EngGetFi ePath DDI; va trebui să fie ușor corectat manual Un tip inteligent a folosit înregistrarea WCHAR(*pDest)[MAX PATH+l], când a declarat al doilea parametru; analizorul nostru simplu nu poate face asta Mai jos este cel mai mic dintre cele trei fișiere ini care conțin definițiile GDI API pentru motorul de imprimare EMF [wlnppl] HANDLE GdiGetSpoolFI eHandle(LPWSTR,LPDEVMODEW LPWSTR) BOOL GdiDeleteSpoolFI eHandle(HANDLE) DWORD GdiGetPageCount(HANDLE) HDC GdlGetDC(HANDLE) HANDLE Gd GetPageHandle(HANDLE DWORD LPDWORD) BOOL GdiSta rtDocEMF(HANDL E DOCINFOW*) BOOL GdiPIayPageEMF(HANDLE HANDLE RECT* RECT* RECT*) BOOL GdiEndPageEMF(HANDLE DWORD) BOOL GdiEndDocEMF(HANDLE) BOOL GdiGetDevmodeForPage(HANDLE DWORD PDEVMODEW* PDEVMODEW*) BOOL GdiResetDCEMF(HANDLE PDEVMODEW) [tipuri] MÂNERE LPWSTR LPDEVMODEW BOOL DWORD HDC LPDWORD DOCINFOW* RECT* PDEVMODEW* PDEVMODEW Capitolul Monitorizarea sistemului grafic Windows După cum puteți vedea din lista de mai sus, fișierul de definiție API este format din două secțiuni Prima secțiune listează prototipurile de funcții simplificate, iar a doua secțiune listează tipurile de date unice utilizate de aceste funcții Win GDI folosește modulul de ferestre (USER DLL) pentru a crea mediul în care are loc majoritatea rezultatelor grafice Modulul USER conține o serie de funcții API interesante care ar fi de asemenea utile de urmat - BeginPaint, EndPaint, GetDC, etc Pe baza acestui lucru, vom folosi programul Skimmer și vom genera fișierul winuser ini din fișierul winuser h Decodor de date GDI Programul Skimmer enumeră toate tipurile de date implicate într-un grup de funcții API; aceste informații sunt folosite de cercetătorul DLL Pentru a face datele salvate mai ușor de citit, avem nevoie de un decodor special care să funcționeze cu anumite tipuri de date GDI - cum ar fi HGDIOBJ, LOGFONTW și chiar DEVMODEW, dacă aceste informații sunt de interes pentru cineva Cu cunoștințele despre structurile de date GDI dobândite în Capitolul , sarcina de a construi un DLL de decodor de date GDI este redusă la codare simplă Mai jos este structura de bază a DLL decodorului GDI clasa KGDIDecoder : IDcoder public { ATOM atom HGDIOBJ; public: KGDIDcoderO { pNextDecoder = NULL: } virtual bool Inițial izedAtomTable * pAtomTable): virtual int Decode(ATOM typ, const void * pValue char * szBuffer int nBufferSize): bool KGDIDcoder::InitializedAtomTable * pAtomTable) { if ( pAtomTable==NULL ) returnează fals: atom HGDIOBJ - pAtomTable->AddAtom ("HGDIOBJ"): returnează adevărat: } // Căutați tipuri de obiecte GDI int KGDIDecoder::Decode(ATOM typ const void * pValue char*szBuffer int nBufferSize) Urmărirea apelurilor Win GDI date nesemnate = * (nesemnat *) pValue; dacă ( (typ==atom HDC) || (typ==atom HGDIOBJ) || (typ==atom HPEN) || (typ==atom HBRUSH) || (typ==atom HPALETTE) (typ~=atom HRGN) (typ »»atom HFONT) ) { TCHAR temp[ J: unsigned objtyp = (date » ) & OxFF: dacă ( ! Căutare( objtyp & x F Dic GdiObjectType, temp) ) tcscpy(temp, „HGDIOBJ”): if ( objtyp & x ) // Obiect standard wsprintf(szBuffer "(Sfcs)fcx" temp, date & OxFFFF); el se wsprintf(szBuffer, „(fcs)fcx”, temp, date și OxFFFF): întoarcere ; } Dacă ( typ==atom PLOGFONTW ) { LOGFONTW * pLogFont - (LOGFONTW *) date: dacă ( ! IsBadReadPtr(pLogFont sizeof(LOGFONTW)) ) { wsprintf(szBuffer „& LOGFONTW{^d Xd fcws}” pLogFont-> fHei ght pLogFont-> fWi dth, pLogFont->lfFaceName): întoarcere : } } // Tipurile brute returnează ; } KGDIDcoder GDIDcoder: extern "C" declspec(dl export) IDcoder * WINAPI Create GDI Decoder(void) { return și codificator GDID: } Clasa KGDIDecoder este un decodor simplu pentru tipurile de date GDI bazat pe clasa de bază IDecoder (similar cu implementarea interfețelor COM în clasele COM) Funcția Create GDI Decoder returnează un pointer către instanța globală a KGDIDecoder (la fel ca și fabrica de clase pentru clasa COM) Scout-ul încarcă DLL-ul decodor GDI în timpul Capitolul Monitorizarea sistemului grafic Windows work, primește adresa funcției de creator, o apelează și apoi inițializează decodorul folosind metoda KGDIDecoder->Initialize Decodoare noi sunt apoi conectate peste cele vechi și apelate în secvență pentru a converti datele primite în format text până când cererea este procesată După cum am văzut în Capitolul , mânerul obiectului Windows NT/ GDI este format din trei părți: o unicitate de biți, un identificator de tip de biți și un index de biți Programul nostru folosește aceste informații pentru a extrage numele tipului și indexul din manipulator Pentru indicatorii către o structură LOGFONTW, programul scoate datele logice ale fontului: înălțime, lățime și numele tipului Comutarea DLL-ului scout la noul decodor îmbunătățește considerabil calitatea ieșirii Fiecare mâner de obiect GDI este acum etichetat de tip Rezultatul arată acum o secvență clară de acțiuni: aplicația creează un obiect GDI, îl selectează, îl folosește, apoi îl decontextează și, în final, îl șterge Implementarea noilor capabilități de decodor va face posibilă introducerea de noi îmbunătățiri în procesul de monitorizare API Monitorizare completă API Până acum, ne-am conectat la lanțul de procesare a apelurilor API modificând directorul de import al modulului Astfel, la modificarea directorului de import al modulului CLOCK EXE pentru a monitoriza funcția GDI SelectObject, toate apelurile care provin din acest modul sunt interceptate (cu excepția cazului în care programul se gândește să apeleze SelectObject indirect folosind GetProcAddress) Cu toate acestea, multe componente ale ferestrei (cum ar fi bara de titlu, titlul, meniurile și pictogramele) nu sunt desenate direct de programul dvs - astfel de sarcini grafice sunt gestionate de funcția standard de fereastră într-un mod predeterminat În programele MFC care utilizează versiunea DLL a bibliotecii, multe funcții grafice GDI sunt apelate din DLL MFC (de exemplu, MFC DLL sau MFC D DLL pentru MFC versiunea ) Dacă doriți să monitorizați apelurile grafice de la toate aceste module prin modificarea directorului de import, va trebui să le enumerați în fișierul ip al programului monitorizat În acest caz, DLL-ul scout va trebui să parcurgă toate modulele și să le editeze directoarele de import Dar chiar și listarea tuturor modulelor procesului nu garantează succesul complet În timp ce programul rulează, pot fi încărcate module noi (de exemplu, COM DLL) despre care nu știați dinainte Și dacă asta nu este suficient, luați în considerare că atunci când apelați funcții exportate GDI din GDI , directorul de import nu este folosit deloc În acest caz, are loc un apel direct intra-modul (ip-tramodule); constructe precum caii [ Imp SelectObJ] nu participă la el Pentru a monitoriza pe deplin apelurile API la nivel de proces (adică, interceptați toate apelurile din interiorul și din exteriorul modulului în care se află implementarea; de la modulele deja încărcate și cele care vor fi încărcate ulterior), trebuie să modificați implementarea API în sine De exemplu, dacă găsiți adresa funcției SelectObject în GDI DLL și modificați funcția în sine, toate apelurile către SelectObject vor trece prin codul dvs Urmărirea apelurilor Win GDI Modificarea programului este ușoară Este mult mai dificil să faci ca aplicația să funcționeze la fel după modificare După cum se arată în secțiunea „Urmărirea apelurilor funcției API Win ”, dorim să inserăm câteva rânduri de cod de asamblare în funcție, astfel încât apelul funcției API să transfere automat controlul către handlerul nostru de intrare După ieșirea din handler, funcția API originală trebuie să fie executată cu exact aceleași valori de registru După finalizarea funcției API, handlerul nostru de ieșire trebuie apelat înainte de a returna controlul apelantului Principala problemă este că, din cauza modificării punctului de intrare al funcției API, atunci când handlerul de intrare se termină, controlul nu poate fi transferat către intrarea funcției modificate Există două soluții principale la această problemă În primul caz, handlerul de intrare restabilește starea anterioară a punctului de intrare, astfel încât, atunci când revine, controlul este transferat implementării API-ului original Această soluție este ideală pentru o înregistrare unică, dar unde să faceți corecții pentru apelurile ulterioare? Cel mai natural ar fi să facem acest lucru într-un handler de ieșire, dar asta înseamnă că nu vom putea procesa apeluri recursive, precum și apeluri din alte fire de execuție a programului, în timp ce funcția API se execută Astfel, ajungem la a doua soluție - nu pentru a restabili secțiunea modificată, ci pentru a muta punctul de intrare în funcție Când se modifică intrarea inițială în funcția API, trebuie alocați cel puțin octeți pentru instrucțiunea de salt necondiționat pentru funcția stub, ceea ce duce la deteriorarea mai multor instrucțiuni Instrucțiunile corupte pot fi copiate într-un buffer din interiorul DLL-ului scout și urmate de un salt la prima instrucțiune după secțiunea deteriorată Când toate acestea sunt făcute, singurul lucru care mai rămâne de făcut este să permiteți handler-ului de intrare al DLL-ului scout să transfere controlul către instrucțiunile relocate Următorul exemplu vă va ajuta să înțelegeți mai bine ce se întâmplă Să ne uităm la câteva instrucțiuni inițiale pentru funcția SelectObject în limbaj de asamblare și în cod nativ SelectObjectQ : push ebp V EU mov ebp special push ecx FC și dword ptr [ebp- ] SelectObject@ + : Cei cinci octeți care încep cu SelectObject@ vor fi necesari pentru mica noastră intervenție chirurgicală; aceasta va corupe instrucțiuni pentru un total de octeți Salvăm primii octeți ai Sel ectObject@ și scriem o instrucțiune de salt necondiționat în stub la această adresă SelectObJect@ : e хх хх хх хх Select bject@ + : jmp Stub SelectObject@ por por Capitolul Monitorizarea sistemului grafic Windows Vă rugăm să rețineți că de fapt folosim doar octeți, dar pentru ca programul să funcționeze corect, trei instrucțiuni goale sunt incluse în el Codul stub arată astfel: Stub-Select bject@ : apăsați Index-Selectobject jmp ProxyProlog New Select bject@ : împinge ebp mov ebp special împinge ecx și dword ptr [ebp- ], jmp Select bject@ + Acordați atenție la câteva detalii interesante În primul rând, Stub Select bject@ conține exact același cod ca în soluția noastră anterioară, cu modificări la directorul de import În al doilea rând, funcția New SelectObject@ recreează începutul funcției Select bject@ înainte de modificare Aceste potriviri ne permit să reutilizam tot codul implicat în soluție cu modificarea directorului de import, cu o singură excepție: trebuie să setăm pFuncTable->m func[index selectobject] f olddaddress la New Select- bject@ , astfel încât atunci când ProxyProlog revine, execuția să urmeze aceeași cale, ca atunci când utilizați funcția API originală Cu toate acestea, încă nu am luat în considerare partea cea mai dificilă a soluției cu codul în mișcare - sarcina aparent simplă de a calcula numărul de octeți de mutat Am aflat deja că numărul minim este de octeți, dar nu este ușor să determinați valoarea exactă, deoarece trebuie copiate numai instrucțiuni întregi Pentru procesoarele Intel, nu există reguli simple pentru calcularea lungimii instrucțiunilor din primii câțiva octeți Ca urmare a adăugării constante de noi instrucțiuni la setul original , situația a devenit incredibil de complicată Un program de numărare de octeți care funcționează pentru instrucțiuni întregi de cel puțin octeți este, de fapt, „scheletul” unui dezasamblator Pe vremea lui Winl , sarcina era mult mai ușor de rezolvat, deoarece toate funcțiile exportate aveau același prolog Odată cu apariția codului pe de biți și a compilatoarelor cu optimizări îmbunătățite (și în special pentru procesoarele cu mai multe conducte de instrucțiuni), a devenit imposibil de prezis cu ce instrucțiune începe o funcție Pe parcurs, apare o altă problemă - nu toate instrucțiunile pot fi mutate prin simpla copiere Comenzile de transfer de control (cum ar fi jmp) folosesc adesea adrese relative în funcție de locația curentă a comenzii în memorie Pentru a muta o astfel de comandă, ar trebui să actualizați offset-ul relativ În implementarea noastră actuală, prologurile de funcții cu salturi de offset relative nu sunt acceptate Biblioteca statică Patcher lib, care este inclusă cu Diver dll, implementează modificarea relocarii Pentru a indica faptul că doriți să utilizați interceptarea la nivel de proces, setați numele modulului apelant și al modulului apelat cu același nume De exemplu, următorul fișier ini oferă conectarea la nivel de proces pentru funcțiile GDI listate în wingdi ini și funcțiile USER listate în winuser ini: Urmărirea apelurilor Win GDI [Modul] gdi dll Gdi DLL, wingdi User dll User DLL, Winuser La interceptarea la nivel de proces, numeroase funcții API GDI care sunt apelate din alte DLL-uri de sistem - cum ar fi USER DLL, COMDLG DLL, COMCTL DLL, OLE DLL și chiar din GDI DLL însuși Veți vedea că USER DLL apeluri la GDI DLL pentru a efectua operațiuni grafice, că GDI DLL combină apelurile de funcții API în apeluri de funcții generice sau invers, împarte funcțiile API complexe în altele mai simple Astfel, vei putea urmări spectacolul „în culise” Un mic exemplu este prezentat în Fig Lroyowy? Г І І (SHPALETTE)b i : (HBITMAP) c ? ADEVĂRAT ? -NEGRU ■" G ? ALB D i (HBITMAP) c unu h Enter: Leaver Return Caller : : HBITMAP( c ): CARDS dll+ e "' *'b ta"''b T b '^nbc) ( :'uSER dll+c l' " r І /" : : h - " — І : (SHBITMAP)f ' ' G ' ^ ALB' g r“ І NEGRU ? ? % ^ ? : : : : i (HBITMAP) c ' " (SHPĂLEffE)b zG Y g ; USER dll+c eu USER dll+c : USER dll+c c ; UTILIZATOR dii+c e i USER dil+c f : USER dii+ca e : GDI DLL+ baa i GDI DLL bbb ȚGDI DLL bd " : GD DLL+ c a" ; GDÎ DLL cl'c" GDO DLL C : GDI DLL+ c Ș USER dii+ca f ' EU UTILIZATOR dii+ca a ■ UTILIZATOR dii+ca Calee just r d III Lo ad Bit m ap A j usei djjiGețpC Gd I dl IIC re at eC omp at i bl e B it m ap j user dlHReleaseDC i Gdi dllSelectObject ?Gdi dil!SetBkC^ i Gdi dlHSettextColor lGdi dniSetbiBits \Gdi dll!ȘavebC j Gdi dllSelectObject j Gdi ;diilȘeiectPalețte i Gdi diiiSetblBitsfobevice T Gdi i diiiSeiectPaietțe i Gdi dllSelectObject [Gdi dll!ResțorepC i Gdi dllSetTextColor lGdi djjiȘetBkCoipr" I Gdi dllSelectObject Orez Monitorizarea completă a apelurilor API oferă o perspectivă asupra implementării LoadBitmap Apelurile API prezentate în figură sunt sortate în ordinea în care sunt procesate Prima coloană indică nivelul de imbricare; în al doilea - valoarea returnată; al treilea este adresa apelantului, iar al patrulea este numele funcției apelate Valorile parametrilor nu sunt afișate pentru a economisi spațiu Rețineți că fișierele generate direct nu sunt sortate după ora de intrare, ci după ora de ieșire Au fost folosite instrumente de sortare Excel pentru a simplifica analiza datelor Dacă vă uitați cu atenție la figură, veți înțelege că aveți o implementare „secretă” a funcției LoadBitmap Funcția LoadBitmap este acceptată de managerul de ferestre (USER DLL) și este concepută pentru a încărca o hartă de bit într-un format GDI dependent de hardware Cu toate acestea, nu știm din documentație cum este implementată această caracteristică După cum puteți vedea din figură, LoadBitmapA (versiunea ANSI a LoadBitmap) apelează mai multe funcții GDI pentru a converti un bitmap independent de dispozitiv într-un bitmap dependent de dispozitiv Funcția CreateCompatibleBitmap creează un nou bitmap DDB, iar funcția SetDIBits realizează transformarea Figura arată, de asemenea, modul în care funcția SetDIBits este implementată în GDI - se rezumă la un apel către SetDIBitsToDevice Capitolul Monitorizarea sistemului grafic Windows Urmărirea interfețelor COM DirectDraw DirectDraw API, ca și alte interfețe DirectX API, se bazează pe tehnologia Microsoft COM (Component Object Model) Funcționalitatea DirectDraw este oferită utilizatorului sub forma mai multor interfețe COM, cum ar fi IDirectDraw și IDirectDrawSurface O interfață COM este definită ca un grup de funcții (sau metode) legate semantic De exemplu, metodele interfeței IDirectDrawSurface sunt concepute pentru a funcționa cu suprafețele DirectDraw, iar metodele interfeței IDirectDraw-Clipper controlează tăierea suprafețelor DirectDraw Să vedem cum să organizăm monitorizarea acestor metode Tabelul funcțiilor virtuale Metodele de interfață COM sunt apelate printr-un pointer de interfață, care este de fapt un pointer către un obiect C++ cu o reprezentare a datelor necunoscută Singurul lucru pe care îl știe partea clientului este că obiectul COM începe cu un pointer către tabelul de funcții virtuale Acest tabel conține indicatorii către funcții care implementează toate metodele interfeței și urmează într-o anumită ordine Toate interfețele COM derivă din interfața IUnknown, care definește trei metode: Query-Interface, AddRef și Release Aceasta înseamnă că primii trei pointeri din tabelul de funcții virtuale COM implementează întotdeauna acele trei metode În mod obișnuit, un tabel de funcții virtuale C++ sau COM este generat de compilator într-o zonă de date globale de numai citire sau de citire/scriere Există o analogie cu variabilele interne utilizate de directorul de import al modulului pentru a stoca adresele funcțiilor importate Din punct de vedere tehnic, nu este dificil să interceptați apelurile către metode ale unei interfețe COM sau ale unei interfețe DirectDraw Tot ceea ce este necesar pentru aceasta este să găsim adresele tuturor tabelelor de funcții virtuale care ne interesează și apoi să înlocuim indicatorii de funcție stocați în ele cu indicatorii către stub-urile DLL scout Obținerea adresei tabelului de funcții virtuale pentru o interfață COM obișnuită este ușor Găsiți GUID-urile de clasă și de interfață, apelați CoCreatelnstance și implementarea COM a sistemului de operare va încărca serverul COM corect, va crea obiectul COM și vă va returna indicatorul de interfață Primii octeți ai blocului, referiți de indicatorul de interfață, vă vor oferi adresa tabelului de funcții virtuale pe care îl căutați Majoritatea interfețelor DirectDraw nu sunt create de apelul standard către CoCreatelstance De exemplu, singura modalitate de a crea un pointer de interfață pentru un IDirectDrawSurface este apelând metoda CreateSurface pe interfața IDirectDraw În contextul DirectDraw, acest lucru este perfect logic, deoarece suprafețele DirectDraw sunt întotdeauna gestionate de obiecte DirectDraw DLL-ul de recunoaștere ar trebui să aibă un impact minim asupra funcționării sistemului Prin urmare, crearea unui obiect DirectDraw și a unei suprafețe DirectDraw doar pentru a obține un tabel de funcții virtuale IDirectDrawSurface ar fi nedorită Soluție alternativă - obțineți date Urmărirea interfețelor COM DirectDraw tabele de funcții virtuale offline, într-un program separat, salvați-le într-un fișier ini și apoi utilizați-le în procesul de urmărire Programul Query-DDraw face exact asta Încearcă să creeze cât mai mulți indicatori de interfață DirectDraw diferite și înregistrează adresele tabelelor de funcții virtuale, numărul de metode și numele interfeței și GUID Este aproape imposibil de determinat numărul de metode dintr-o clasă în C++, dar un program DirectDraw scris în C trebuie să cunoască acest număr deoarece tabelul de funcții virtuale este simulat folosind o matrice de pointeri de funcție Următorul fragment arată cum să obțineți informațiile necesare pentru interfața IDirectDraw #define INTERFATA #include IDirectDraw * Ipdd: HRESULT hr = DirectDrawCreate(NULL & Ipdd NULL); Dumplninterface(„IID ID rectDraw” IID ID rectDraw lpdd->lpVtbl sizeof(*lpdd->lpVtbl) ): Înainte de a include ddraw h, fișierul antet DirectDraw, este definită macro-ul CINTERFACE Aceasta activează definirea interfețelor COM în stil C, unde tabelul de funcții virtuale este simulat de o serie de pointeri de funcție, iar pointerul către tabelul de funcții virtuale este stocat într-unul dintre câmpurile structurii ( pVtbl) Definiția în stil C a interfețelor COM vă permite să utilizați funcția sizeof(*lpdd->lpVtbl) pentru a calcula dimensiunea unui tabel de funcții virtuale și, prin urmare, numărul de funcții din tabel Apelarea unei metode C++ este oarecum diferită de un apel de funcție normal în C sau Pascal Metodei apelate i se trece implicit un pointer suplimentar obiectului curent (așa-numitul acest pointer) Deși compilatorul C++ acceptă capacitatea de a trece acest pointer în registrele procesorului pentru a îmbunătăți performanța, interfețele COM și interfața DirectDraw trec întotdeauna acest pointer pe stivă Singurul lucru care rămâne de făcut este să spuneți funcției de ieșire a parametrilor DLL-ului scout că există un parametru suplimentar Definiția DirectDraw API Următoarea sarcină este generarea unui fișier ini pentru toate metodele DirectDraw în formatul programului de control Pogy Pentru a face acest lucru, cel mai simplu parser de fișiere antet C, Skimmer, trebuie să facă câteva modificări În primul rând, începutul declarației interfeței COM trebuie determinat de prefixul DECLARE INTERFACEj; în al doilea rând, programul trebuie să proceseze macrocomenzile STDMETHOD și STDMETHOD- pentru a restabili tipul de returnare și numele funcției; în al treilea rând, macrocomenzile THIS și THIS- trebuie de asemenea procesate pentru a trece acest pointer ca parametru suplimentar Următoarea este o versiune editată a definiției API-ului DirectDraw completă, precisă și lipsită de ambiguitate [ddraw] HRESULT DirectDrawEnumerateW(LPPENUMCALLBACKW LPVOID) Capitolul Monitorizarea sistemului grafic Windows HRESULT DlrectDrawEnumerateA(LPPENUMCALLBACKA LPVOID) HRESULT DirectDrawEnumerateExW(LPPENUMCALLBACKEXW,LPVOID DWORD) HRESULT DirectDrawEnumerateExA(LPPENUMCALLВACKEXA LPVOID,DWORD) HRESULT DirectDrawCreate(GUID*,LPDIRECTDRAW* lunknown*) HRESULT DirectDrawCreateCli pper(DWORD LPDIRECTDRAWCLIPPER* lunknown*) [Tragerea COM] a a { cl db -a -llce-a - - - -af- b-e - } IID IDirectDraw O eO a {b a f eO- b -llcf-a -de-OO-aa- -b - - } IID IDirectDraw a a { c a- bd-lldl- c- a- -c - f-d - -c } IID IDirectDraw fO { cl db -a -llce-a - - - -af- b-e - } IID IDi rectDrawSurface [IDirectDraw] HRESULT QueryInterface(THIS,REFIID LPVOID*) ULONG AddRef(THIS) Lansare ULONG (ACESTA) ULONG Compact(ACESTA) HRESULT CreateClipper(THIS DWORD LPDIRECTDRAWCLIPPER* lunknown) HRESULT CreatePalette(THIS,DWORD,LPPALETTEENTRY, LPDIRECTDRAWPALETTE* lunknown) HRESULT CreateSurface(THIS,LPDDSURFACEDESC, LPDIRECTDRAWSURFACE* lunknown) Prima secțiune listează funcțiile obișnuite exportate din DDRAW DLL Această bibliotecă exportă destul de multe funcții Aceasta listează funcțiile documentate în ddraw h; alte funcții (cum ar fi DIIGetClassObject) sunt exporturi COM standard; altele sunt documentate în alte fișiere antet sau nu sunt documentate deloc A doua secțiune conține informații despre interfețele COM generate de programul QueryDDraw Pentru fiecare interfață COM DirectDraw, sunt specificate adresa tabelului de funcții virtuale, adresa primei funcție virtuale (QueryInterface), numărul de metode, GUID-ul și numele interfeței Această secțiune este reconstruită pentru fiecare sistem de operare și pachete de servicii instalate Următoarele secțiuni descriu prototipurile metodei în detaliu (o secțiune pentru fiecare interfață) Secțiunea de mai sus este doar pentru interfața IDirectDraw Interfața IDirectDraw adaugă doar o nouă metodă în comparație cu IDirectDraw, în timp ce IDirectDraw adaugă două metode noi la interfața IDirectDraw Modificarea tabelului de funcții virtuale Conținutul fișierului de definiție DirectDraw API este citit de programul de control și transmis cercetătorului DLL Scout-ul construiește un tabel de interfață care listează numele, GUID-ul, adresa tabelului de funcții virtuale, adresa QueryInterface și numărul de metode pentru fiecare interfață Procesul inițial Urmărirea apelurilor de sistem GDI După inițializare, încarcă COM DLL (în acest caz, ddraw dll), găsește toate tabelele de funcții virtuale enumerate și se asigură că primul său element se potrivește cu adresa cunoscută a metodei QueryInterface DLL-ul scout apelează apoi următoarea funcție pentru a modifica toate metodele DirectDraw enumerate: BOOL HackMethod(uris gned vtable, int n, FARPROC newfunc) { DWORD cBytesWritten: Wr teProcessMemory(GetCurrentProcess(), (LPVOID) (vtable + n * ) & newfunc, sizeof(newfunc), &cBytesWritten); returnează cBytesWritten == sizeof(newfunc): } Parametrul newfunc indică funcția stub descrisă în secțiunea „Urmărirea apelurilor de funcție API Win ” După modificare, totul funcționează la fel ca atunci când editați directorul de import Mai jos este un mic exemplu pentru interfața IDirectDraw HRESULT(O) ddraw dll!SetCooperafiveLevel x b , HWND( cc) HRESULT( ) ddraw dll!SetDisplayMode x b HRESULT(O) ddraw dll! x b , LPDDSURFACEDESC( fe ) LPDIRECTDRAWSURFACE*( ff c) Necunoscut*( ) ULONG(O) ddraw dllIRlease x b După cum puteți vedea din secvența de apeluri de mai sus, după ce obiectul DirectDraw este creat, aplicația apelează metodele SetCooperativeLevel, SetDisplayMode și CreateSurface ale interfeței IDirectDraw și apoi distruge obiectul cu metoda Release Primul parametru, x b , este acest indicator După cum puteți vedea, decodorul de tip de date al DirectDraw este foarte util Urmărirea apelurilor de sistem GDI Din analiza a trei tipuri diferite de urmărire a apelurilor API, trecem la ceva care nu este acoperit în documentație Da, este vorba despre funcțiile sistemului GDI, interfața dintre clientul GDI în modul utilizator și motorul grafic în modul kernel După cum sa menționat mai sus, DirectDraw, Direct D și OpenGL folosesc GDI pentru a accesa funcțiile utilitare ale motorului grafic Capitolul , despre arhitectura sistemului grafic Windows NT/ , arată că funcțiile de sistem ale sistemului grafic joacă un rol foarte important - sunt responsabile pentru transmiterea cererilor de ieșire grafică Capitolul Monitorizarea sistemului grafic Windows de la modul utilizator la motorul grafic al modului kernel și driverele de dispozitiv Cu toate acestea, funcțiile de sistem (și mai ales funcțiile de sistem ale sistemului grafic) nu sunt menționate în documentația oficială Capitolul a introdus programul SysCall, care este conceput pentru a căuta apeluri de funcții de sistem în DLL-urile clientului subsistemului Win - și anume, GDI DLL, USER DLL și KERNEL DLL Cu ajutorul fișierelor de depanare ale numelor simbolice, programul enumerează toate apelurile la funcțiile sistemului cu indici, număr de parametri, adrese și nume simbolice Poate chiar scoate date despre tabelul de funcții ale sistemului în spațiul de adrese al nucleului Dar, deoarece manevrele de funcții de sistem din motorul GUI corespund apelurilor de funcții în modul utilizator, ne va fi mult mai ușor să urmărim partea de utilizator a acestei interfețe nedocumentate Lista generată de programul SysCall nu satisface nevoile noastre Trebuie făcute unele îmbunătățiri, astfel încât programul să genereze o listă de prototipuri de funcție Spre deosebire de alte modificări, dorim ca adresele acestor funcții să fie afișate împreună cu prototipurile În caz contrar, programul scout va trebui să folosească nume simbolice de depanare în timpul rulării, ceea ce îl va face mai puțin generic O nouă comandă de meniu a fost adăugată la programul SysCall, apelurile de sistem GDI pentru Pogy Mai jos este doar o mică parte din lista apelurilor de funcții de sistem din GDI DLL [gdisyscall] D NtGdiCreateEl ipticRgn(DD,DD), F AB D NtGdiDdGetBltStatus(DD), F A D NtGdiGetDeviceGammaRamp(DD), F D a D NtGdiSTROBJjjwGetCodePage(D), F CB D NtGdiGetTextExtentExW(DDDD,DD,D,D) F C , c D NtGdiGetColorAdjustment(DD) F BB a! D NtGdiFlushO, F F , D NtGdiDdSetOverlayPosltion(DDD) F F, d D NtGdiPATHOBJJbEnumClipLines(DDD), F CD D NtGdiEngCreateBitmap(D,DDD,DD), F B CD D NtGdiColorCreatePalette(DD,D,DD,D) F F D NtGdiDdDestroySurface(D,D), F AAB D NtGdiDdRenderMoComp(DD), F , Poate ați observat că nu avem informații precise despre tipurile de parametri și valorile returnate Singurul lucru pe care îl știm este numărul de parametri, care este determinat de numărul de octeți ieșiți din stivă la întoarcere Deci etichetăm fiecare parametru cu tipul D (prescurtare de la DWORD) și amânăm înlocuirea lor cu tipuri mai semnificative până când devin disponibile mai multe informații Există o serie de modificări care trebuie făcute DLL-ului scout În primul rând, adresa funcției este cunoscută, așa că nu sunt necesare trucuri precum GetProcAddress pentru Win API Cu toate acestea, programul trebuie să se asigure că această adresă conține cod în formatul unui apel de funcție de sistem: Urmărirea apelurilor de sistem GDI NtGdi SysCall xx muta eax functionjndex NtGdi SysCall xx+ : lea edx [sp+ ] int x e ret parameter number * În principiu, s-ar putea folosi metoda de modificare a relocarii folosită pentru a intercepta apelurile API la nivel de proces, dar este ușor de observat că instrucțiunile de după NtGdi SysCall xx+ există într-un număr limitat de variante - câte una pentru fiecare număr de parametri Numărul de parametri trecuți la apelarea funcțiilor sistemului GDI variază de la la Prin urmare, avem nevoie doar de funcții pentru a înlocui codul în urma primei instrucțiuni (stocarea indexului) După modificare, codul arată astfel: NtGdi SysCall xx muta eax functionjndex NtGdi SysCa xx+ : jmp Stub NtGdi SysCall xx Stub NtGdi SysCall xx push func id jmp ProxyProlog La întoarcerea de la ProxyProlog, trebuie să transferăm controlul către una dintre funcțiile în care funcțiile sistemului sunt apelate direct: // Pentru funcțiile de sistem cu doi parametri declspec(naked) void SysCall (void) { asm lea edx [sp+ ] asm int x e asm ret x } Interceptarea apelurilor de sistem ar fi mult mai ușoară dacă nu am folosi funcțiile de cercetare de bază ProxyProlog, ProxyEntry, ProxyEpilog și ProxyExit Monitorizarea funcțiilor sistemului grafic este un lucru foarte interesant, deoarece este foarte diferit de monitorizarea obișnuită a funcțiilor API Descrierile detaliate despre acest subiect sunt rareori găsite în cărți și reviste Și urmărirea apelurilor API GDI împreună cu apelurile la funcții de sistem este și mai interesantă Este posibil ca nimeni să nu fi făcut asta încă API-ul GDI este interfața dintre aplicație și motorul de suport pentru sistemul de operare în modul utilizator, iar funcțiile sistemului grafic sunt interfața dintre GDI și motorul grafic în modul kernel Așa că urmărim ambele părți ale clientului GDI DLL GDI DLL Diferențele dintre ele arată clar ce se întâmplă exact în DLL-ul client GDI În tabel Figura prezintă o versiune editată a protocolului cu monitorizarea simultană a apelurilor GDI și a funcțiilor sistemului grafic Capitolul Monitorizarea sistemului grafic Windows Tabelul Protocolul de apelare a funcției Win GDI și exemplu de funcții de sistem Level Nesting rezultat Apel de funcție (SHFONT) SelectObject((HDC) , (HFONT) el) ALB SetBkColor((HDC) ,a c a ) SetTextAlign((HDC) ) BLACK SetTextCol sau ((HDO , BLACK) TRUE NtGdiDeleteObjectApp((HPEN) d ) TRUE Delete bject((HPEN) d ) TRUE DeleteObjectC(HBRUSH) e ) (SHBRUSH)IO GetStockObject( ) (SHPEN) NtGdi GetStockObject( ) (SHPEN) GetStock bject( ) (HFONT) el NtGdiHfontCreate( x f c x x x x ) (HFONT) el CreateFontIndirectExW(ENUML GF NTEXDVW*( f c )) TRUE NtGdi GetWi dthTable((HDC) ,Oxb, xl b x , xl d e, xl b ) TRUE GetTextExtentPoi ntW( (HDO LPCWSTR( a ), , LPSIZE( fac )) HBITMAP( d ) NtGdi CreateCompati bl eBi tmap( (HDO x x ) HBITMAP( d ) CreateCompatibleBi tmap((HDC) , , ) HBITMAP( d ) TRUE NtGdi dreptunghi ((HDC) e x x x x ) dreptunghi TRUE((HDC) e , , , , ) Rețineți că funcțiile cu un nivel mai ridicat de imbricare sunt apelate de funcțiile de nivel inferior care le urmează în protocol Protocoalele primite confirmă unele dintre faptele menționate în capitolele precedente O parte a structurii de date a contextului dispozitivului este implementată în modul utilizator, astfel încât cererile simple de context sunt gestionate ușor și eficient în modul utilizator, fără a fi nevoie să apelați funcțiile din modul nucleu al sistemului A Tabelul de obiecte GDI este gestionat de motorul grafic, astfel încât funcțiile de sistem sunt apelate atunci când obiectele sunt create și distruse Perii și regiunile dreptunghiulare ocupă un loc special - GDI Urmărirea interfeței DDI memorează în cache obiectele șterse pentru reutilizare Vedem că ștergerea HPEN apelează funcția NtGdi DeleteObjectApp, în timp ce ștergerea HBRUSH nu duce întotdeauna la un apel de sistem Despre CreateDiscardableBitmap este doar CreateCompatibleBitmap A Comenzile grafice se traduc de obicei direct în funcțiile sistemului A Funcțiile sistemului GDI funcționează pe aproape aceleași tipuri de date ca și funcțiile Win GDI API În esență, acum aveți un set de instrumente grozav pentru a face cercetări GDI pe cont propriu Puteți să vă planificați propriul experiment în zona GDI API care vă interesează, să setați parametrii de monitorizare corespunzători, să efectuați un test și să analizați rezultatele Urmărirea interfeței DDI În cele patru secțiuni anterioare ale acestui capitol, am discutat în detaliu posibilitățile de monitorizare a sistemului grafic Windows în modul utilizator Acum putem monitoriza atât interfața GDI de intrare, cât și de ieșire Și acum este timpul să trecem la un nou „teritoriu” - la motorul grafic al modului kernel DLL-urile subsistemului Win accesează motorul grafic apelând funcțiile sistemului În capitolul , am introdus programul SysCall, care afișează o listă completă de apeluri de funcții de sistem (atât grafice, cât și legate de ferestre) Listele de funcții GDI și USER care folosesc apeluri de sistem coincid aproape complet cu lista de gestionare a funcțiilor de sistem WIN K SYS Singura diferență este că unele funcții de sistem nu sunt apelate în DLL-urile de sistem în modul utilizator Monitorizarea funcțiilor sistemului grafic în modul kernel nu aduce multe informații noi, deoarece putem monitoriza cu ușurință apelurile de sistem în modul utilizator Desigur, există avantaje în a urmări această interfață din partea nucleului - se face la nivelul întregului sistem, și nu la nivelul unui anumit proces Pe de altă parte, astfel de experimente afectează prea mult funcționarea întregului sistem Cel mai interesant aspect grafic al modului kernel este interfața DDI dintre motorul grafic și driverele de dispozitiv După cum am menționat în capitolul , motorul grafic trebuie să lucreze din greu pentru a converti apelurile GDI în apeluri DDI, deoarece acestea se află la diferite niveluri de abstractizare Secțiunea „Drifere de imprimantă” din Capitolul a introdus un driver de imprimantă simplu care generează documente HTML în loc de comenzi de imprimantă Paginile HTML conțin liste de apeluri DDI cu depozite de parametri hexazecimale și hărți de biți color pe de biți redate la dpi Driverul nostru HTML simplu este potrivit pentru experimentarea cu interfața DDI Cu toate acestea, această opțiune este limitată la driverul de imprimantă și la un set fix de opțiuni Desigur, este de dorit să existe o soluție mai generală care Capitolul Monitorizarea sistemului grafic Windows ar ține evidența tuturor driverelor grafice, ecranelor, imprimantelor, plotterelor și chiar și a aparatelor de fax Capitolul acoperă structurile de date interne de bază ale GDI și motorul grafic în detaliu În special, a spus că obiectul kernel al fiecărui context de dispozitiv conține un pointer către o structură PDEV care conține toate informațiile despre dispozitivul fizic pentru motorul grafic Structura PDEV este creată după ce driverul de ecran este încărcat apelând funcțiile DrvEnableDriver, DrvEnablePDEV și, în final, DrvCompletePDEV Prin urmare, PDEV conține toate informațiile primite de la driverul dispozitivului grafic atunci când sunt apelate aceste funcții, inclusiv punctele de intrare DDI Pe Windows , ultimul bloc de date al structurii PDEV conține de indicatori de funcție; în Windows NT poate conține până la de indicatori de funcție Este foarte ușor să lucrați cu indicatori de funcție atunci când monitorizați apelurile API A trebuit deja să modificăm pointerii din tabelul de import DLL și din tabelele de funcții virtuale C++/COM O serie de indicatori de funcție într-o structură PDEV are multe în comun cu un tabel de funcții virtuale Dintre acești de indicatoare, destul de multe nu sunt folosite, rămân rezervate sau nu sunt implementate în mod normal de driverul de dispozitiv Chiar și monitorizarea a - de apeluri DDI ar însemna că am făcut o treabă destul de bună Având în vedere că acest număr este destul de mic în comparație cu de funcții GDI, am putea scrie doar - de funcții DDI intermediare în loc să ne ocupăm de instrucțiunile de asamblare în spațiul de adrese kernel Programul pentru monitorizarea apelurilor GDI (precum și pentru monitorizarea funcțiilor API în modul utilizator) este format din două componente Driverul în modul kernel este încărcat în spațiul de adrese kernel, este inclus în lanțul de procesare a apelurilor DDI, primește informații despre parametri și le transmite programului de control Daemonul în modul utilizator pornește și oprește driverul, îi transmite comenzi și primește datele capturate Driverul pentru modul kernel, DDISpy SYS, este o versiune ușor extinsă a driverului Periscope folosit în Capitolul Driverul Periscope a gestionat doar o singură instrucțiune I/O pentru a citi un bloc de date din spațiul de adrese kernel, ceea ce ne-a ajutat mult atunci când investighăm structurile de date interne ale GDI DDISpy procesează cele patru comenzi I/O enumerate în Tabelul Tabelul Comenzi I/O DDISpy Cod comandă Parametri Funcție DDISPY READ Adresă, dimensiune Aceeași ca Periscope, bloc de date citit din spațiul de adrese kernel DDISPY-START adresa tabelului de funcții DDI, număr Modificați conținutul tabelului de funcții (porniți monitorizarea apelurilor DDI) Urmărirea interfeței DDI Cod comandă Parametri Funcție DDISPYEND Adresa tabelului Restabiliți conținutul tabelului cu funcții DDI, numărul ts (sfârșitul monitorizării apelului DDI) DDISPYREPORT Dimensiune Transferul informațiilor colectate către programul de control Pentru fiecare funcție DDI, este creată o funcție intermediară corespunzătoare care înregistrează datele, apelează funcția originală și, opțional, înregistrează valoarea returnată a acesteia Cronometrarea nu este efectuată în acest caz, deoarece măsuram performanța generală a GDI în modul utilizator De asemenea, nu ne facem griji cu privire la salvarea registrelor, știind că, după regulile DDI, registrele sunt folosite doar pentru a returna o valoare a funcției Într-un cuvânt, fără asamblare - cod solid C Mai jos este cea mai interesantă parte a DDISpy - funcții intermediare typedef struct PFN PFN PROXYFN; pProxy: pReal; PROXYFN DDI Proxy [] = // Listare în ordinea indexului funcției DDI (PFN) DrvEnablePDEV, NULL (PFN) DrvCompletePDEV, NULL (PFN) DrvDisablePDEV, NULL, (PFN) DrvEnableSurface, NULL (PFN) DrvDisableSurface NUL (PFN) NULL, NULL, (PFN) NUL NUL (PFN) DrvResetPDEV NUL }; void DDISpy Start(unsigned fntable int count) { nesemnat * pFuncTable = (nesemnat *) fntable: // Ștergeți tamponul pentru (int i= : i OxaOOOOOOO ) // Indicator valid if ( DDI Proxy[i] pProxy != NULL ) // Există o funcție intermediară { // Amintiți-vă adresa reală a funcției numite DDI Proxy[i] pReal = (PFN) pFuncTable[i]; // Fix pFuncTable[i] s (nesemnat) DDI Proxy[i] pProxy: Capitolul Monitorizarea sistemului grafic Windows void DDISpy Stop(unsigned fntable Int count) { nesemnat * pFuncTable = (nesemnat *) fntable; pentru (Int = : OxaOOOOOOO ) // Indicator valid If ( DDI Proxy[ ] pProxy != NULL ) // Există o funcție intermediară { // Returnează adresa veche pFuncTable[ ] = (nesemnat) DDI Proxy[ ] pReal: } } #def ne Apel(nume) (*(PFN ## nume) \ DDI Proxy[INDEX ## numeJ pReal) void APIENTRY DrvDIsableDrlver(vold) { WrlteCDisableDriver"); Caii(DrvDisableDriver)(); } BOOL APIENTRY DrvTextOut(SURFOBJ *pso STROBJ *pstro FONTOBJ*pfo CLIPOBJ*pco, RECTL *prclExtra, RECTL *prclOpaque, BRUSHOBJ *pboFore, BRUSHOBJ *pboOpaque, POINTL *pptlOrg, Mix mix) ( Scrie ("DrvTextOut"); h return Caii(DrvTextOut) (pso pstro pfo pco prclExtra prclOpaque pboFore, pboOpaque pptlOrg, mix); } Utilizarea macro-ului Caii este justificată de faptul că face programul mai descriptiv Această macrocomandă indică un indicator de funcție DDI real către tabelul DDI Proxy, îl convertește în tipul corect de indicator al funcției DDI și apelează acea funcție Apropo, ați observat lipsa unor astfel de cârlige API în limbaje de nivel înalt? Când este apelată o funcție DDI reală, un cadru de stivă este duplicat Daemonul DDIWatcher nu este deosebit de problematic deoarece are multe asemănări cu programul TestPeriScope din Capitolul Mai jos este cea mai importantă funcție numită după instalarea driverului de kernel KDDIWatcher::SpyOnDDI(void) ( buf nesemnat[ ]; HDC hDC = GetDC(NULL): // Creați contextul dispozitivului Rezultate typedef nesemnat (CALLBACK * ProcO) (vold): ProcO pGdiQueryTable = (ProcO) GetProcAddress( GetModuleHandle ("GDI DLL") "GdiQueryTable"): assert(pGDIQueryTable): // Obține adresa tabelului de obiecte GDI nesemnat * addr = (nesemnat *) (pGDIQueryTable() + (nesemnat) hDC & OxFFFF) * ): // Intrare în tabel pentru hDC addr = (nesemnat *) addr[ ]; // Pointer către obiectul nucleului scope Read(buf, addr ): // Citiți dwords # fdef NT pdev nesemnat = buf[ ]: // PDEV * unsigned fntable = pdev + x F : // Tabel de funcții #altfel pdev nesemnat = buf[ ]: // PDEV * fntable nesemnat = pdev + xB C: // Tabel de funcții #endi f // Citiți tabelul de funcții pentru a verifica, DrvScope scope Read(buf, (void *) fntable, * ): cmd nesemnat[ ] = { fntable, }: nesemnat lung dwRead: // Începeți snoopingul DDI loControl(DDISPY-START, cmd, slzeof(cmd), buf, , &dwRead): // Adăugați apeluri grafice sau mutați fereastra pe desktop // Opriți snoopingul DDI loControl(DDISPY END, cmd slzeof(cmd) buf &dwRead): cmd[l] = slzeof(buf): // Citiți datele înregistrate loControl(DDISPY REPORT cmd, sizeof(cmd), buf, slzeof(buf), &dwRead): // Afișează datele primite } Deci, avem un program pentru monitorizarea interfeței DDI care funcționează cu orice driver de dispozitiv grafic Funcționarea programului se bazează pe modificarea structurii de date a mecanismului GDI în memorie Chiar dacă acest lucru duce la blocarea computerului și la un ecran albastru (ceea ce este puțin probabil), puteți oricând să reporniți computerul și să-l restabiliți în stare de funcționare Rezultate Acest capitol a introdus diverse instrumente pentru investigarea logicii modului în care funcționează GDI Secțiunea „Monitorizarea apelurilor de funcție API Win ” descrie principiile generale ale monitorizării apelurilor API Secțiunea „Urmărirea apelurilor Win GDI” ilustrează o tehnică de monitorizare a tuturor apelurilor de funcții Capitolul Monitorizarea sistemului grafic Windows Intrări GDI în proces, atât din GDI DLL, cât și din module externe În secțiunea „Urmărirea interfețelor COM DirectDraw”, ne-am concentrat pe interfețele COM utilizate în DirectDraw Secțiunea Monitorizarea apelurilor de sistem GDI discută în detaliu monitorizarea apelurilor către funcțiile sistemului grafic Capitolul se încheie cu secțiunea Monitorizare DDI despre conectarea DDI folosind noul driver pentru modul kernel Folosind instrumentele dezvoltate în acest capitol, puteți monitoriza API-ul Win GDI/DirectDraw și puteți observa dinamica apelurilor GDI/DirectDraw la nivel de proces sau modul Prin monitorizarea funcțiilor de sistem nedocumentate ale sistemului grafic, veți vedea cum GDI DLL se bazează pe suportul motorului grafic pentru a funcționa Dacă sunteți mai interesat de detaliile reale despre modul în care motorul grafic interacționează cu driverul dispozitivului, aveți la dispoziție și un instrument simplu, dar puternic, de monitorizare a apelurilor DDI În plus, aveți chiar și un utilitar pentru construirea automată a fișierelor de definiție API și un mecanism pentru scrierea modulelor de extensie care oferă o gestionare avansată sau personalizată a tipurilor de date Deși acest capitol se concentrează pe GDI și DirectDraw, soluțiile prezentate sunt de natură generală și pot fi utilizate cu alte părți ale Win API și alte interfețe COM „Dă-mi o funcție API și îți voi arăta unde te va duce acest apel sau cel puțin am toate instrumentele pentru a afla ” Acum îl puteți revendica cu drepturi depline Exemple de programe Exemplele de programe din Capitolul (Tabelul ), ca și exemplele de programe din Capitolul , nu sunt exemple tipice de programare grafică Mai degrabă, sunt utilități de sistem sofisticate concepute pentru a analiza funcționarea subsistemului grafic Windows și principiile generale ale structurii interne a sistemului de operare Windows Utilizați pentru sănătate Tabelul Capitolul Programe Descriere director de proiect Samples\Chapt \Patcher Funcție biblioteca de modificare a prologului pentru a trece la codul stub Samples\Chapt \Skimmer Program pentru extragerea definițiilor API din fișierele antet SDK Samples\Chapt \Diver Un DLL de recunoaștere care este injectat în procesul investigat pentru a colecta informații Samples\Chapt \Pogy Monitoring daemon; instalează un cârlig Windows pentru a injecta un DLL scout numit Diver Rezultate Descriere director de proiect Samples\Chapt \PogyGDI Decodor de tip de date GDI (descărcat de la Diver) Samples\Chapt \QueryDDraw Helper program pentru construirea unui fișier de definiție DirectDraw API Samples\Chapt \DDISpy Driver în modul Kernel pentru monitorizarea funcțiilor DDI Samples\Chapt \DDIWatcher Program de testare pentru monitorizarea apelurilor DDI folosind programul DDISpy Capitolul Abstracția dispozitivului grafic După cum știți, printre toate API-urile pentru programarea grafică în Windows, locul central este ocupat de GDI (Graphics Device Interface) DirectDraw, noul API grafic D al Microsoft, este orientat spre programarea jocurilor, în timp ce interfața Direct D este proiectată pentru jocuri și aplicații D Toate aceste API-uri grafice sunt interfețe de programare independente de hardware, care permit aplicațiilor scrise folosindu-le să ruleze pe diferite dispozitive grafice Pentru a asigura independența hardware a API-ului grafic, este necesară o abstractizare bună care să permită reprezentarea diferitelor dispozitive grafice și mascarea diferențelor acestora fără pierderi de performanță Acest capitol descrie mecanismul principal de abstractizare a dispozitivelor grafice în GDI, contextul dispozitivului (DC) Ne vom familiariza cu capacitățile adaptoarelor video moderne, cu reprezentarea unui dispozitiv grafic abstract sub forma unui context de dispozitiv, precum și cu interacțiunea unui context de dispozitiv cu modulul de ferestre OS Adaptoare video moderne API-ul grafic din sistemul Windows se concentrează în primul rând pe lucrul cu adaptorul video ca mijloc principal de interacțiune între utilizator și computer S-ar putea să fii surprins cât de complex este un adaptor video modern În industria PC-urilor, computerele pe de biți sunt abia la orizont, iar manualul adaptorului video precizează că folosește o arhitectură de de biți Este posibil ca programele dumneavoastră să ruleze pe Windows NT Adaptoare video moderne cu de megaocteți de memorie, iar adaptorul dvs video utilizează aceeași cantitate de memorie cu adresare pe de biți pentru propriile scopuri Dar cel mai incredibil lucru este că adaptorul video este capabil să efectueze până la miliarde de operații reale pe secundă, iar codul Windows NT în modul kernel simulează operațiuni reale folosind numere întregi Luați în considerare principalele componente ale unui adaptor video modern framebuffer Toate adaptoarele video moderne funcționează pe o bază raster; aceasta înseamnă că informațiile din ele sunt stocate sub formă de rețele bidimensionale de pixeli în zona de memorie a adaptorului video Această zonă de memorie se numește frame buffer Tampoanele de cadru vin în diferite dimensiuni Când oamenii vorbesc despre dimensiunea ecranului, de obicei înseamnă „rezoluție” Această caracteristică este fundamental diferită de rezoluția, măsurată în dots per inch (dpi), utilizată pe scară largă pentru imprimante Rezoluția ecranului se referă în general la numărul de pixeli care pot fi afișați vertical și orizontal pe un ecran; rezoluția imprimantei este de obicei înțeleasă ca numărul de pixeli adresabili independent pe inch Buffer-ul minim de cadre acceptat de Windows este dimensiunea standard VGA de de pixeli pe linie pe de linii Această dimensiune a fost folosită pentru prima dată de IBM pe computerele PS/ De obicei, x este întâlnit doar la pornirea computerului în modul sigur sau când rulați programe vechi care vă obligă să comutați ecranul la această dimensiune Dimensiunile maxime ale framebuffer-ului pot ajunge la x și chiar x pixeli Vă rugăm să rețineți că pentru majoritatea rezoluțiilor, lățimea și înălțimea ecranului sunt într-un raport de : - de exemplu, x , x , x și chiar x Această proporție corespunde raportului de lățimea până la înălțimea monitorului însuși, datorită căreia pixelii vecini de pe ecran sunt la aceeași distanță pe verticală și pe orizontală În funcție de numărul de culori reproduse în framebuffer, pixelii pot fi reprezentați prin numere diferite de biți Într-un cadru tampon monocrom, un pixel este reprezentat doar de un bit, în timp ce într-un cadru tampon cu culori, sunt utilizați biți per pixel În noua generație de adaptoare video, aceste moduri de culoare practic nu se găsesc Un framebuffer în zilele noastre conține minimum de culori, fiecare pixel fiind reprezentat de biți (sau un octet) Așa-numitele moduri High Color sunt adesea folosite, care codifică un pixel pe sau biți; aceasta permite reprezentarea a ( K) sau ( K) culori, deși în ambele cazuri un pixel este codificat cu octeți Din ce în ce mai mult, adaptoarele video acceptă moduri True Color, în care de biți sunt utilizați pentru a reprezenta ( M) culori diferite Unele moduri folosesc chiar și o codare de pixeli de de biți, deși acest lucru nu înseamnă că există de culori în aceste moduri; De obicei, sunt necesari biți pentru a stoca datele canalului alfa, lăsând doar de biți pentru a reprezenta informațiile de culoare Capitolul Abstracția dispozitivului grafic Pentru ca driverul de dispozitiv grafic să iasă în framebuffer, framebuffer-ul trebuie mapat la spațiul de adrese al procesorului Primele PC-uri utilizau linii de adresă de de biți, permițând spațiu de adresă de până la MB Adaptorul video a primit doar sau KB din spațiul total de adrese de megaoctet Primele adaptoare video Super-VGA cu rezoluție de x și de culori necesitau un cadru tampon de KB, cu mult peste micuții KB Prin urmare, în loc să stocheze framebuffer-ul ca un bloc continuu de x x octeți de echipament, acesta a trebuit să fie împărțit în opt planuri de culoare (planuri) x x bit Fiecare avion ocupa doar KB, ceea ce a făcut posibilă utilizarea unui adaptor video pe un PC Ca urmare a împărțirii pixelilor în opt planuri, pentru a scrie un pixel în memoria tampon de cadru, a fost necesar să introduceți comanda de mapare a planului la spațiul de adresă al procesorului din registrul hardware, actualizarea unui bit, trecerea la următorul plan, etc Uneori, producătorii de echipamente împărțeau tampoane mari de cadru în mai multe bănci (bănci) sau foloseau avioane simultan cu băncile După cum ați putea ghici, toate acestea au făcut destul de dificilă implementarea unei interfețe GDI independentă de hardware Drept urmare, Microsoft a introdus conceptul de bitmap dependent de dispozitiv (DDB), care a permis producătorilor de hardware să ofere suport pentru traducerea rapidă a bitmap-urilor în și din propriul format framebuffer Pe Windows NT/ , întregul sistem, inclusiv subsistemul grafic, rulează într-un spațiu de adrese de de biți Cantitatea din acest spațiu ( GB) lasă suficient spațiu pentru orice cadru tampon În legătură cu promovarea activă a DirectX, Microsoft cere ca noile adaptoare video să accepte tampon de cadre liniare cu pixeli împachetati „Ambalare” înseamnă că toți pixelii trebuie să fie împreună, fără a fi împărțiți în planuri de culoare Liniaritatea înseamnă că întregul framebuffer poate fi mapat la un spațiu de adrese liniar de de biți Pe măsură ce biți pe pixel și rezoluția cresc, este necesară din ce în ce mai multă memorie pentru a stoca întregul framebuffer În tabel Tabelul listează cantitatea de memorie necesară pentru a stoca un framebuffer la diferite rezoluții și formate de pixeli Tabelul Geometrie cadru tampon Permisiune Raport lățime/înălțime Cantitatea de memorie pentru stocarea memoriei tampon, KB biți , biți biți biți x : x : x : x : Adaptoare video moderne Raport de rezoluție Cantitatea de memorie pentru stocarea memoriei tampon, KB "lățime/ înălțime" biți , biți biți biți x : x : x : x : Modul maxim acceptat de adaptorul video al autorului folosește o rezoluție de x cu un buffer de cadru de de biți și o rată de reîmprospătare verticală de Hz Aceasta înseamnă că în fiecare secundă, acest adaptor video citește întregul framebuffer de de kiloocteți de de ori și îl convertește într-un semnal video Astfel, pe secundă, adaptorul video trebuie să proceseze MB de informații; devine clar de ce are nevoie de memorie sincronă rapidă de de rânduri La o rezoluție de x la de biți/pixel, o linie de scanare este reprezentată de cel puțin de octeți Specificația Microsoft necesită ca liniile de scanare să fie aliniate în framebuffer-ul pe o limită de cuvinte duble de de biți pentru a îmbunătăți performanța memoriei Un volum de de octeți îndeplinește această cerință În același timp, linia de scanare nu trebuie să aibă o lungime exactă de de octeți - trebuie doar să fie de cel puțin Capitolul Abstracția dispozitivului grafic această valoare Astfel, producătorilor de echipamente li se oferă o oarecare flexibilitate în modul de aliniere a liniilor de scanare Dimensiunea unei linii de scanare din framebuffer se numește pitch În structura framebuffer prezentată în Fig , tamponul este o matrice de linii de scanare, iar dimensiunea fiecărui element al matricei este determinată de pasul tamponului Într-o linie de scanare, fiecare pixel este reprezentat de un anumit număr de biți sau octeți adiacenți De exemplu, pentru un buffer de cadru de de biți/pixel, un pixel este reprezentat de trei octeți care determină intensitatea componentelor de culoare în secvența albastru-verde-roșu Următoarea funcție calculează adresa unui pixel având în vedere adresa de pornire a framebuffer-ului, pasul, dimensiunea și poziția relativă a pixelului în buffer: char *GetPixelAddress(char * buffer, Int pitch int byteperpixel int x, int y) { return buffer + y * pitch + x * byteperpixel; } Format pixel Când te uiți la un obiect, lumina reflectată de el intră în ochii tăi Lumina este aceeași radiație electromagnetică ca, de exemplu, undele radio, microunde, infraroșu și raze X sau raze gamma Ochiul uman percepe doar o mică parte din întregul spectru electromagnetic, care se numește lumină vizibilă și se află în intervalul de lungimi de undă de la la nm Culorile diferite corespund unor lungimi de undă diferite în spectrul luminii vizibile În ochii noștri există celule speciale, așa-numitele conuri; sunt sensibili la aceste lungimi de undă și ne permit să vedem lumea în culoare Trei tipuri diferite de conuri sunt afectate de lumină în părțile roșii, verzi și albastre ale spectrului Aceste trei culori sunt numite primare Lumina generată de diferite surse aparține diferitelor părți ale spectrului și este percepută ca având o culoare sau alta În industria computerelor, culoarea este de obicei descrisă ca o combinație de trei componente de culoare primară - roșu, verde și albastru O culoare poate fi gândită ca un punct dintr-un spațiu de culoare tridimensional în care componentele corespund la trei axe (așa-numitul spațiu de culoare RGB) În literatura de grafică pe computer, componentele de culoare sunt de obicei reprezentate ca numere reale cuprinse între și , ceea ce permite descrierea unui număr infinit de culori Dar în lumea discretă a adaptoarelor video moderne, fiecare componentă este de obicei convertită într-un număr întreg între și , reprezentat în spațiul de memorie de opt biți sau un octet Astfel, culoarea unui pixel este descrisă de trei octeți - câte unul pentru componentele roșie, verde și albastră, iar spațiul de culoare RGB discret de de biți poate descrie până la de culori diferite Într-un framebuffer monocrom, fiecare pixel este reprezentat de un bit de memorie Informațiile despre opt pixeli sunt împachetate într-un octet, în timp ce Adaptoare video moderne bitul cel mai semnificativ corespunde primului pixel, iar bitul cel mai puțin semnificativ corespunde ultimului pixel Probabil că nu va trebui să utilizați un buffer monocrom pentru ieșire directă, dar tamponurile monocrome joacă încă un rol semnificativ în programarea Windows în zilele noastre Într-un framebuffer de culoare, planurile de culoare sunt reprezentate în format tampon monocrom Formatul monocrom este adesea folosit pentru a reprezenta hărți de biți în memorie — de exemplu, glifele de font sunt de obicei convertite în hărți de biți monocrome înainte de a fi afișate sau trimise la o imprimantă Imprimantele monocolor funcționează și cu unele varietati de ecrane monocrome la nivelul limbajului imprimantei sau al microcodului intern Reprezentarea unui singur pixel cu biți permite utilizarea a până la de culori diferite Dacă aceste culori ar fi fixate rigid, ar trebui să alegem un set universal de puncte care să reprezinte întregul spațiu de culoare RGB - acest lucru nu este în mod clar suficient pentru o afișare normală a lumii noastre multicolore Prin urmare, în loc de un set fix de culori, adaptorul video folosește un tabel de culori numit paletă Pentru un framebuffer codificat pe biți, paleta constă din de elemente, fiecare corespunzând unei valori RGB de de biți Framebuffer-ul nu stochează culori, ci indexează în paletă Cu o reprezentare indirectă a culorilor paletată, framebuffer-ul conține încă doar de culori diferite la un moment dat, dar aceste culori sunt alese dintre milioane de candidați în spațiul de culoare pe de biți De exemplu, o paletă cu de nuanțe de gri poate afișa radiografii, în timp ce o paletă cu tonuri calde de culori roșiatice-portocalii este bună pentru imaginile apusului Când se actualizează un cadru tampon care utilizează o paletă, adaptorul video trebuie să citească indecșii din buffer, să îi ruleze prin tabelul de culori și să trimită datele rezultate la portul video La nivel hardware, acest proces este implementat foarte eficient În acest caz, driverul de dispozitiv trebuie să ofere puncte de intrare pentru programele de nivel înalt pentru a controla paleta hardware Dacă anumite valori de culoare RGB sunt specificate în comenzile grafice în loc de indici de paletă, acestea trebuie convertite în indici de paletă atunci când pixelii sunt scrisi sau invers când pixelii sunt citiți Procesul de conversie a valorilor RGB în indici de paletă este o chestiune de a căuta în tabel și de a căuta cea mai exactă potrivire Dacă nu poate fi găsită o potrivire exactă, culoarea poate fi simulată printr-un model de pixeli incluși în paletă folosind algoritmul de dithering Convertirea indicilor paletei în valori RGB se face prin indexare simplă Pe fig Figura ilustrează procesul de determinare a culorilor pentru un framebuffer codificat pe biți/pixel În tampoanele de cadru High Color de biți, fiecare dintre componentele de culoare primară este reprezentată de biți Informațiile despre un pixel sunt stocate într-un cuvânt de biți; bitul cel mai semnificativ este lăsat nedefinit, urmat de biți de roșu, biți de verde și cel mai puțin semnificativ biți de albastru Formatul de pixeli de biți este adesea denumit „ : : ” Framebuffer-ul în acest format poate conține până la de culori diferite Capitolul Abstracția dispozitivului grafic Index pe biți din GPU framebuffer II III paleta hardware FF FF AA !LJ L^ FF AA Semnal roșu Semnal verde -k Semnal albastru -k Orez Căutare în paletă pentru framebuffer pe biți Formatul High Color ( biți) se îmbunătățește ușor față de formatul pe biți În loc să piardă pur și simplu bitul cel mai semnificativ dintr-un cuvânt de biți, componenta verde este extinsă la biți, deoarece ochiul uman este mai sensibil la verde Într-un cadru tampon de biți, un pixel este încă reprezentat de un cuvânt de biți, de obicei într-un format : : În comparație cu tampoanele pentru cadre True Color, utilizarea formatului High Color economisește memorie la un număr normal de culori și rezoluții înalte De exemplu, un adaptor video cu doar megaocteți de memorie în modul biți poate suporta rezoluții de până la x Cu toate acestea, există un dezavantaj - viteza Scrierea unui pixel de culoare dintr-un format RGB pe de biți într-un framebuffer High Color este mai mult decât o simplă copiere Componentele de biți trebuie reduse la sau biți, combinați în funcție de formatul pixelului, și numai atunci datele sunt stocate Convertirea unui pixel dintr-un framebuffer High Color într-un format True Color pe de biți înseamnă extragerea fiecărei componente de culoare cu o mască și extinderea acesteia la biți Există mai multe variante ale formatului de pixel intern, totuși Microsoft cere producătorilor de hardware să utilizeze o structură fixă de framebuffer În plus, un adaptor video care acceptă tampoane de cadre pe biți, dar care nu acceptă tampoane de cadre pe biți, trebuie să imite în continuare suportul pentru tampoane pe biți Aceste cerințe îmbunătățesc compatibilitatea programelor cu diverse dispozitive Pe fig Figura prezintă formatul pixelilor în buffer-uri de cadru de și biți și măști pentru extragerea componentelor roșii, verzi și albastre În aplicațiile și jocurile cu grafică intensivă, chiar și bufferele de cadru cu și rânduri nu oferă diversitatea și netezimea necesară a culorilor pentru tranzițiile de culoare De exemplu, atunci când se afișează o imagine în tonuri de gri folosind un buffer de cadru de biți, pot fi ieșite numai de niveluri de gri - fiecare componentă de culoare RGB este stocată pe biți, ceea ce permite utilizarea a de niveluri de intensitate Astfel de Adaptoare video moderne aplicațiile trebuie pur și simplu să utilizeze cele mai bune - sau de biți True Color frame buffer În ambele buffer-uri de cadre pe de biți și pe de biți, componentele roșii, verzi și albastre sunt reprezentate de biți La adaptoarele video mai vechi, cei biți superiori ai unui pixel de de biți erau de obicei lăsați neutilizați Noile adaptoare video pentru Windows sau Windows stochează informații despre transparență în cei biți superiori format de pixeli de biți | Roșu ( x C ) | Verde (ОхОЗЕО) | Albastru ( x F) | RRRRRGGGGG V V V V V Bit înalt Bit scăzut format de pixeli de biți | Roșu ( xF ) | Verde ( x E ) | Albastru ( x F) | RRRRRGGGGGG V V V V V Orez Format de pixeli în buffer-uri de cadre High Color Componenta de transparență este de obicei numită canal alfa (canal alfa) Această caracteristică determină coeficientul de greutate al pixelului original atunci când este afișat pe suprafață Coeficientul alfa minim este ; asta înseamnă că pixelul este absolut transparent și nu apare deloc la suprafață Valoarea maximă alfa într-un canal alfa de biți este În acest caz, pixelul este complet opac, așa că pur și simplu înlocuiește pixelul corespunzător pe suprafața de recepție Pentru orice valoare intermediară, noul pixel de suprafață este calculat ca suma ponderată a pixelului copiat și a vechiului pixel de suprafață de primire Formatul de pixeli de de biți este adesea denumit „format RGB”, iar formatul de pixeli de de biți „format ARGB” Structura pixelilor în ambele formate este prezentată în Fig Cu de culori diferite reprezentate de un cadru tampon de de biți sau de biți, există suficiente pentru toată lumea, de la fotograful amator până la profesioniștii de ultimă generație Cu toate acestea, a devenit treptat clar că, odată cu utilizarea pe scară largă a modurilor High Color și True Color, s-a pierdut flexibilitatea inerentă paletelor hardware O mică schimbare în paleta hardware s-a reflectat imediat pe întregul ecran De exemplu, dacă un artist a dorit să ajusteze ușor saturația gamei de culori a unui tablou, ar trebui să modifice valorile RGB în cel mult de elemente de paletă Dar, cu structura tradițională a bufferelor de cadre High Color și True Color, este necesar să se schimbe toți pixelii bufferului, a căror dimensiune totală la o rezoluție de x și codare pe de biți a fost de KB La ieșirea de imagini de înaltă calitate, a apărut o altă problemă - potrivirea culorilor de pe ecran cu culorile imaginii imprimate Culoarea afișată pe un dispozitiv electronic nu este percepută de ochii noștri Capitolul Abstracția dispozitivului grafic exact ca pe hârtie Artiștii profesioniști folosesc ceea ce este cunoscut sub numele de corecție gamma, care oferă o transformare suplimentară a pixelilor de culoare din framebuffer Pentru ca tabelul de conversie să aibă o dimensiune rezonabilă, fiecare dintre componentele RGB este convertită într-un tabel separat, care necesită trei tabele de de octeți fiecare La nivel hardware, această conversie este realizată de cipul RAMDAC (RAM digital-to-analog converter) Microsoft necesită adaptoare video pentru a suporta cipuri RAMDAC descărcabile pentru bufferele de cadre True Color pentru a efectua corecția gama în hardware dispozitiv -Dispozitiv Natw șir de dispozitiv; •' Steaguri Stete: DevicelD: Z , '-v, , ~ Dispozitiv Ke^ ■» DîspleyMcdes: |\\\DISPLY Grafică Blaster Riva TNT ATASAT LA DESKTOP PCI WEN J ODE WEVJ &SUBSYS J \RE GIS TRY\Machine\System\ControlS et pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb bv , biți' Hz' Kb W' G/ IMIIIMMMMIM Orez Formate de pixeli pe și de biți Buffering dublu, z-buffer și texturi În jocurile pe calculator, unul dintre locurile centrale este ocupat de animație - imagini mici și chiar ecrane întregi, al căror aspect se modifică în timp Pentru fiecare cadru din secvența de animație, programul trebuie să ștergă unele părți din framebuffer și să deseneze o nouă imagine peste zonele șterse În schema cu un singur framebuffer, semnalul video este generat din conținutul framebuffer-ului în momentul în care programul îl șterge și îl redesenează Rezultatul este o pâlpâire enervantă Adaptoare video moderne Problema este rezolvată prin utilizarea a două buffere - principala (pe ecran) și auxiliară (în afara ecranului) Utilizatorul vede întotdeauna pe ecran doar conținutul buffer-ului principal terminat, în timp ce aplicația lucrează la umplerea bufferului off-screen în acest moment Când ieșirea este finalizată, are loc o comutare - tampoanele principale și auxiliare sunt schimbate Utilizatorul vede noul buffer principal, iar programul începe să lucreze pe noul buffer off-screen În acest caz, utilizatorul nu vede niciodată o imagine neterminată, iar animația devine netedă Tehnica utilizării a două buffere se numește dublu buffering Adaptoarele video de nouă generație ar trebui să ofere tampon dublu pentru întregul cadru tampon Utilizarea tamponării duble dublează cantitatea de memorie video necesară Conform tabelului , pentru a suporta un cadru tampon pe de biți la rezoluție de x , adaptorul video necesită acum , MB de memorie video După ce a primit o solicitare de schimbare a bufferelor, adaptorul video trebuie să aștepte retragerea verticală a fasciculului, adică momentul în care un ciclu de reîmprospătare a imaginii este complet încheiat și un nou ciclu nu a început încă Dacă comutarea tamponului nu este sincronizată cu retragerea verticală a fasciculului, pe ecran apare o distorsiune neplăcută În timpul așteptării, programul nu poate scrie date în niciunul dintre cele două buffere, ceea ce irosește timp CPU Pentru a economisi timp pentru sincronizare, se utilizează o schemă de tamponare triplă, în care înregistrarea poate fi efectuată în al treilea cadru tampon În acest caz, primul buffer conține imaginea care urmează să fie afișată pe ecran, al doilea buffer așteaptă ieșirea și un nou cadru este construit în al treilea buffer În jocurile D, scena constă din diferite obiecte aflate la distanțe diferite de privitor Obiectele din apropiere blochează linia de vedere, ceea ce face ca obiectele îndepărtate să fie parțial sau complet ascunse Pentru a desena o scenă tridimensională, programul trebuie să sorteze obiectele în funcție de distanța față de privitor, iar acesta este un proces foarte complex și îndelungat Situația este complicată de faptul că pixelii unui obiect grafic pot fi localizați și la distanțe diferite față de utilizator (în funcție de locația lor pe obiect) Două obiecte care se ating, de asemenea, se pot suprapune parțial Ca de obicei, o soluție eficientă la problemă este asociată cu costuri suplimentare de memorie Utilizează un tampon suplimentar de adâncime, numit z-buffer (după numele celei de-a treia axe de coordonate) Bufferul z stochează adâncimea fiecărui pixel, adică distanța de la pixelul obiectului până la vizualizator Când este solicitat un nou pixel, adâncimea acestuia este comparată cu adâncimea corespunzătoare din bufferul z Sunt afișați doar pixelii cu o adâncime mai mică, în timp ce conținutul bufferului z este actualizat în același timp Cantitatea de z-buffer din memorie depinde de câte niveluri de adâncime discrete trebuie să distingă programul Bufferul z de biți oferă de niveluri de adâncime; pentru orice scop non-trivial, acest lucru nu este suficient Bufferele z pe biți măresc numărul de niveluri de adâncime la și sunt foarte comune în adaptoarele video de astăzi de pe piață Dar în zilele noastre, cerințele pentru detaliile imaginii în jocuri sunt în continuă creștere Capitolul Abstracția dispozitivului grafic aici, chiar și un z-buffer de biți poate să nu fie suficient La afișarea obiectelor cu o ordine eronată de adâncime, apare așa-numita spălare z (z-aliasing) Din ce în ce mai mult, există adaptoare video cu z-buffer-uri pe și de biți Unele adaptoare video acceptă z-buffer-uri reale, care măresc precizia măsurătorilor de adâncime Un z-buffer pe biți mărește dimensiunea memoriei video cu încă , - , MB Când utilizați un z-buffer pe de biți, această valoare se dublează și ajunge la , - , MB Obiectele și scenele tridimensionale sunt formate din suprafețe tridimensionale, care sunt de obicei construite din mii de triunghiuri elementare Aceste triunghiuri sunt apoi suprapuse cu raster numite texturi, care fac ca suprafața să arate ca o îmbrăcăminte, un banc de nisip sau un zid de cărămidă Cu accelerarea hardware, maparea texturii este realizată de hardware-ul adaptorului video, nu de procesorul computerului Factorul cheie de performanță în acest caz este accesul rapid la texturi; pentru a face acest lucru, adaptorul video trebuie să stocheze rasterele de textură în memoria video în loc să le recupereze din memoria de sistem printr-o magistrală de sistem lentă și puternic încărcată Deci, bufferele principale și off-screen, z-buffer-ul și, în plus, megaocteți de rastere de textură sunt stocați în memoria adaptorului video În tabel arată configurațiile posibile ale adaptorului dvs video Tabelul Alocarea memoriei video Utilizare MB MB MB Tampoane principale KB KB KB x x x x x x Buffer-uri offscreen KB KB KB x x x x x x x x x Z-buffere KB KB KB x x x x x x Texturi KB KB KB După cum se arată în tabel, dacă adaptorul dvs video are MB de memorie, la x cu culoare pe de biți, bufferul principal are KB, cele două buffer-uri în afara ecranului iau un total de KB și - bit z-buffer necesită încă KB; pentru hărți de biți de textură, rămân KB Dar dacă treci la o rezoluție de x , care rămâne cu mult sub maximul de x , mai rămân doar KB pentru texturi O modalitate de a rezolva această problemă este compresia, care reduce dimensiunea texturilor O altă modalitate posibilă este de a accelera încărcarea texturilor din memoria sistemului în memoria adaptorului video În arhitectura hardware PC modernă, transferul de date, inclusiv transferul din memoria sistemului în memoria video, se realizează prin magistrala PCI (Peripheral Component Interconnect) Adaptoare video moderne Rata maximă de transfer a magistralei PCI este de Mbps Noua magistrală AGP (Accelerated Graphics Port), proiectată de Intel, este o magistrală specializată de mare viteză care oferă acces rapid la texturile din memoria sistemului De exemplu, rata de transfer a magistralei AGP X este de Mbps Adaptoarele video pot suporta și suprafețe suprapuse, adică suprafețe care sunt suprapuse pe ecranul principal În special, acest lucru vă permite să transmiteți un semnal de televiziune pe un ecran convențional Accelerarea hardware Funcțiile unui adaptor video modern nu se limitează la furnizarea de cadre tampon pe care programul afișează o imagine și la generarea unui semnal video din conținutul tamponului În caz contrar, puterea de calcul chiar și a celui mai rapid procesor de uz general nu ar fi suficientă pentru a reda un film tridimensional la o rată de cadre acceptabilă Unele dintre caracteristicile acceptate de majoritatea adaptoarelor video sunt enumerate mai jos О Ieșire cursor, inclusiv canal alfa О Suport pentru grafică D: linii și curbe cu posibilă utilizare a coordonatelor fracționale, umpleri zone, raster blitting, suprapunere alfa, umpleri gradient, tamponare multiplă și programare RAMDAC O ieșire de text, inclusiv anti-aliasing folosind glife pe mai multe niveluri Un suport pentru grafică D: conductă de operare D, diverse opțiuni de anti-aliasing de textură, mapare a texturii în perspectivă la nivel de pixel, tamponare z, netezire a marginilor, anti-aliasing la nivel de pixel, filtrare anizotropă, texturi paletate etc Despre videoclip: decodare MPEG, decodare DVD, scalare lină cu filtrare, afișare în mai multe ferestre a informațiilor video cu conversie și filtrare a spațiului de culoare, alocarea tastelor de culoare la nivel de pixel, suprapuneri etc Ecranul dispozitivului și enumerarea modului Windows vă permite să utilizați mai multe dispozitive de afișare pe același sistem pentru a afișa desktopul principal, a afișa informații auxiliare sau ecrane în oglindă în NetMeeting Suportul multi-display vă permite să instalați mai multe adaptoare video pe un computer, fiecare conectându-se la un monitor separat Aceste monitoare fie formează un desktop virtual mare, fie funcționează independent unul de celălalt Prima opțiune este utilă în aplicațiile în care dimensiunea dorită a desktopului este mai mare decât monitorul, cum ar fi imprimarea în format mare, programele de publicare desktop sau sistemele de automatizare Capitolul Abstracția dispozitivului grafic funcții de proiectare A doua opțiune este potrivită pentru jocuri pe computer, depanare, tutoriale și prezentări Oglindirea este indispensabilă în cazurile în care doriți să transferați conținutul ecranului către alt utilizator prin rețea Toate comenzile grafice sunt transmise ca pachete de rețea către un alt computer, unde este reprodusă o copie în oglindă a ecranului original Interfața Windows GDI/DDI a fost proiectată inițial ca un protocol de ieșire local - cu alte cuvinte, comenzile grafice GDI trebuiau transmise unui driver de afișare pe același computer Prin aceasta, diferă de protocolul XWindow folosit în lumea UNIX, care a fost conceput ca un protocol de ieșire la distanță Utilizarea XWindow pe stațiile de lucru UNIX vă permite să veniți acasă, să vă conectați la un computer situat într-un birou la câțiva kilometri distanță și să obțineți conținutul ecranului computerului de birou pe computerul de acasă, astfel încât să îl puteți controla de la distanță Există aplicații care vă permit să lucrați cu Windows terminal XWindow în Microsoft Windows În plus, un ecran XWindow poate fi transmis mai multor părți și poate fi permis fiecăruia să-l modifice Înainte de suportul oficial pentru oglindire, dezvoltatorii de aplicații au trebuit să modifice sau să rescrie driverul de afișare pentru a permite transmiterea comenzilor grafice prin rețea Windows a introdus un driver de oglindă separat care „vede” datele transmise driverului de ecran real Fiecare dispozitiv cu ecran este asociat cu un nume unic prin care se poate face referire la dispozitiv în aplicațiile utilizator Numele este dat sub forma \\ \DISPLAYx, unde x este un număr dintr-o secvență care începe de la Rețineți că în programele C/C++ șirul trebuie scris ca WW WDISPLAYx, deoarece simbolul serviciului \ în șiruri de caractere trebuie scăpat Windows a introdus o nouă funcție, EnumDisplayDevices, pentru a enumera toate dispozitivele de afișare instalate pe sistem Funcția de mai jos captează dispozitivele de pe ecran și completează o listă cu numele acestora void AddDisplayDevIces(HWND hLIst) { DISPLAY DEVICEDev: Dev cb = slzeof(Dev); SendMessage(hL st, CBJESETCONTENT, ); pentru (nesemnat = , EnumDisplayDevices(NULL, și Dev, ): ++) SendMessage(hL st, CB ADDSTRING , (LPARAM) Dev DevIceName): SendMessage(hL st, CB SETCURSEL, , ): } Pentru fiecare dispozitiv cu ecran, EnumDisplayDevices populează structura DISPLAY DEVICE cu numele dispozitivului (de exemplu, WADISPLAY ), șirul de descriere a dispozitivului Adaptoare video moderne proprietățile (de exemplu, NVIDIA RIVA TNT), semnalizatoarele de stare (de exemplu, ATACHED TO DESKTOP | MODESPRUNEDI PRIMARY DEVICE), ID-ul dispozitivului Plug-and-Play și cheia de registry Cunoscând numele dispozitivului de afișare, puteți utiliza funcția EnumDi spl aySettings pentru a obține o listă a tuturor formatelor de cadru tampon acceptate de dispozitiv, cu rate de reîmprospătare verticale Următorul exemplu de cod enumerează și listează un șir cu informații scurte despre fiecare format int FrameBufferSIzednt lățime Int helght bpp) { int bytepp - ( bpp + ) / ; // Octet pe pixel Int byteps - ( w dth*bytepp + ) / * : // Bytes per linie de scanare return helght * octeți; // Octet per framebuffer } void AddDisplaySettlngsCHWND hList LPCTSTR pszDevIceName) { DEVMODE dm: dm dmSize * slzeof(DEVMODE); dm dmDrlverExtra * ; SendMessage(hL st, LB RESETCONTENT ); pentru (nesemnat - : EnumD splaySett ngs(pszDev ceName , &dm); ++) { TCHAR szTemp[MAX PATH]; wspr ntf(szTemp T ("*d prin *d *d blts *d Hz *d KB") dm dmPelsWldth dm dmPelsHelght, dm dmBItsPerPel frecvența dm dmDIsplayF FrameBufferSize(dm dmPelsWIdth dm dmPelsHelght dm dmBItsPerPel) / ); SendMessage(hList LB ADDSTRING, (LPARAM)szTemp); } } Pentru fiecare mod, EnumDisplaySettings populează structura DEVMODE cu informații despre lățimea și înălțimea framebuffer-ului, biți pe pixel, rata de reîmprospătare și așa mai departe Funcția de mai sus calculează dimensiunea unui framebuffer pe baza informațiilor primite Rețineți că trebuie avut grijă când utilizați structura DEVMODE API-ul Win a documentat o structură DEVMODE publică Driverul de dispozitiv grafic poate adăuga date private la câmpurile publice DEVMODE specificând dimensiunea datelor suplimentare în câmpul dmDriverExtra Înainte de a apela EnumDisplaySettings, programul completează câmpul dmSize cu dimensiunea Capitolul Abstracția dispozitivului grafic (partea publică) DEVMODE și șterge câmpul dmDriverExtra, astfel încât driverul de ecran să nu încerce să obțină date suplimentare CD-ul inclus conține un program DEVICE care utilizează funcțiile EnumDisplayDevices și EnumDisplaySettings Pagina DisplayDevices afișează o listă de dispozitive de afișare instalate pe sistem și formatele de cadru tampon pe care le acceptă Pe fig prezintă o vedere exemplară a ferestrei programului DEVICE DeyioeNam DevbeSlmg: ' SteteFteg^ l\\ \DI$F'LĂY Grafică Blaster Riva TNT ATACHEDjrO-DESKTOP Dispozitiv: OisptayMcdes: '-DCATtnbutes PCI WEN DE^DEV &SUBSYS \REGISTRY\Machine\System\ControlSet ' pe , biți, Hz, Kb " pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb - pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb pe , biți, Hz, Kb, - bv , biți, Hz Kb JLI • Orez Enumerarea dispozitivelor și modurilor de ecran Contextul dispozitivului Adaptoarele de afișare formează o singură clasă de dispozitive grafice acceptate de sistemul grafic Windows O altă clasă importantă de dispozitive grafice sunt dispozitivele de copiere pe hârtie - imprimante, plotere și faxuri Sistemul grafic Windows NT/ are o arhitectură stratificată Nivelul superior este format din DLL-uri client pe de biți, furnizate Contextul dispozitivului punând la dispoziția aplicațiilor utilizator funcțiile API De exemplu, GDI DLL acceptă funcțiile GDI API pentru grafica D tradițională; DDRAW DLL sunt funcții DirectDraw API pentru programarea graficii D în jocuri, iar D DRM DLL și D DIM DLL sunt funcții Direct D API pentru programarea graficii D a jocurilor DLL-urile client sunt mapate la spațiul de adrese al aplicației (la partea modului utilizator) Stratul de mijloc este motorul grafic care rulează în spațiul de adrese în modul kernel și oferă suport grafic API pentru întregul sistem Spațiul de adrese grafice în modul kernel conține sute de handlere de funcții ale sistemului grafic apelate de DLL-urile client În Windows NT/ , motorul grafic și porțiunea în modul kernel a sistemului de ferestre sunt combinate într-un DLL mare în modul kernel, WIN K SYS Nivelul inferior al sistemului grafic constă din drivere de dispozitive grafice furnizate de producătorii de hardware și care implementează interfața DDI (Device Driver Interface) în conformitate cu specificația Microsoft DDK (Device Driver Kit) Pentru o descriere detaliată a sistemului grafic Windows, a funcțiilor sistemului grafic, a interfeței DDI și a driverelor pentru dispozitive grafice, consultați Capitolul Pentru a comunica cu driverele de dispozitive grafice, sistemul grafic Windows NT/ utilizează o structură internă de date numită context de dispozitiv De fapt, un context de dispozitiv este o ierarhie complexă de structuri și obiecte legate prin pointeri și care rezidă atât în spațiul de adrese în modul utilizator al aplicației, cât și în spațiul de adrese de sistem al nucleului Capitolul analizează în detaliu elementele interne ale contextului dispozitivului și ale altor structuri de date ale sistemului grafic Contextul dispozitivului îndeplinește două sarcini importante într-un sistem grafic Scopul principal este de a abstractiza dispozitivul grafic, astfel încât toate componentele de deasupra driverului de dispozitiv (inclusiv motorul grafic, DLL-urile client Win și aplicația utilizator) să poată fi independente de dispozitiv În plus, atributele grafice utilizate frecvent, cum ar fi culoarea de fundal, operarea bitmap, creionul, pensula, fontul etc sunt stocate în contextul dispozitivului, astfel încât valorile lor să nu fie setate în fiecare comandă grafică DLL-ul client GDI Win ascunde contextul real al dispozitivului din aplicațiile utilizatorului Aplicația este furnizată numai cu un handle de context al dispozitivului, care este un număr de de biți într-un format nedocumentat Hranul este returnat atunci când contextul dispozitivului este creat folosind GDI și apoi este transmis către GDI la toate solicitările ulterioare de a efectua operațiuni grafice Mecanismul de manipulare ascunde implementarea mai sigur decât pointerii C++ și indicatorii de interfață COM De asemenea, extinde foarte mult libertatea Microsoft de a crea implementări interoperabile între sisteme De exemplu, programele Win funcționează atât pe Windows / , cât și pe Windows NT/ , deși manerele de context ale dispozitivului sunt implementate diferit în aceste clase de sisteme Capitolul Abstracția dispozitivului grafic Creați un context de dispozitiv Contextul dispozitivului este creat de funcția Win CreateDC: HDC CreateDC (LPCSTR pszDriver LPCSTR pszDevice, LPCSTR pszOutput, CONST DEVMODE *pdvmlnit): Primul parametru, pszDriver, nu este folosit în programele Win pentru a transmite numele driverului de dispozitiv grafic; este un rest din era Winl API Valorile valide pentru acest parametru sunt doar DISPLAY (contextul dispozitivului de afișare), NULL și WINSPOOL (contextul dispozitivului pentru imprimantă) Al doilea parametru, pszDevice, specifică numele dispozitivului grafic Poate trece fie numele dispozitivului de ecran returnat de funcția EnumDi spl ayDevices, fie numele imprimantei specificat în widget-ul Printers din Panoul de control De exemplu, o valoare WW WDISPLAY sau NULL indică dispozitivul de afișare principal; sens \\\\ WDISPLAY corespunde de obicei dispozitivului de afișare secundar, \\\\ WDISPLAY se poate referi la un driver NetMeeting care oferă oglindirea ecranului pe alt monitor Al treilea parametru specifică numele portului către care este trimisă lucrarea de imprimare Win folosește noua funcție StartDoc pentru a transmite numele portului, astfel încât acest parametru trebuie să fie întotdeauna NULL Ultimul parametru, pdvmlnit, conține un pointer către o structură DEVMODE care descrie parametrii de inițializare În mod normal, este trecut NULL, ceea ce înseamnă că driverul de dispozitiv ar trebui să utilizeze configurația curentă a dispozitivului stocată în registry Pentru dispozitivele cu ecran, pdvmlnit poate indica o structură DEVMODE returnată de funcția EnumDisplaySettings care conține înălțimea, lățimea, biți pe pixel și rata de reîmprospătare verticală Pentru dispozitivele de copiere pe hârtie, pdvmlnit poate indica structura DEVMODE returnată de funcția DocumentProperties Funcția CreateDC returnează un handle de context al dispozitivului GDI care este utilizat în apelurile ulterioare ale funcției GDI până la ultimul apel către DeleteDC, care eliberează resursele de sistem ocupate de contextul dispozitivului; după aceea, manipulatorul de context devine invalid Procesul de creare a unui context de dispozitiv este foarte complex Pe baza numelui dispozitivului, sistemul de operare obține numele driverului de dispozitiv din registru și încarcă driverul Pentru un ecran de monitor, driverul este încărcat numai la primul apel către CreateDC, iar apelurile ulterioare folosesc driverul încărcat anterior Încărcarea și inițializarea efectivă a driverului de imprimantă au loc și atunci când este apelat CreateDC Informațiile despre crearea unui nou context de dispozitiv pentru imprimantă sunt, de asemenea, transmise spooler-ului și DLL-ului care furnizează interfața utilizatorului driverului de imprimantă Când un driver de dispozitiv grafic este încărcat, punctul său de intrare principal este apelat DrvEnableDriver Funcția DrvEnableDriver completează o structură cu numărul versiunii și adresele punctelor de intrare ale tuturor funcțiilor DDI implementate de șofer Motorul grafic apelează apoi funcția DrvEnablePDEV, solicitând driverului să-și descrie atributele și capacitățile și să-și creeze structura Contextul dispozitivului datele dispozitivului fizic Parametrii pdvmlnit și pszDevice trecuți în apelul către CreateDC sunt transferați funcției DrvEnablePDEV Funcția DrvEnablePDEV populează două structuri importante, GDIINFO și DEVINFO, cu informații despre atribute, capabilități, formate de pixeli și setări standard ale dispozitivului Motorul grafic își creează structura fizică internă a dispozitivului cu informațiile returnate de funcțiile DrvEnableDriver și DrvEnablePDEV Acum cunoaște capacitățile dispozitivului grafic și adresele punctelor de intrare la care ar trebui să se refere atunci când apelează diverse comenzi DDI grafice În faza finală a creării contextului dispozitivului, motorul grafic apelează funcția DrvEnable eSurface a driverului; driverul creează o suprafață grafică pe care apare rezultatul real Consultați Capitolul (Descrierea interfeței DDI) și Capitolul (Structuri interne de date) pentru detalii Obținerea de informații despre capabilitățile dispozitivului Contextul dispozitivului stochează (direct sau sub formă de linkuri) o cantitate mare de date despre dispozitivul grafic și driverul acestuia Unele informații pot fi obținute folosind apelurile API Win ; cealaltă parte este stocată în structuri GDI interne pentru a simplifica interacțiunea cu șoferul Funcția GetDeviceCaps returnează informații despre atributele sau capacitățile unui dispozitiv grafic prin index întreg: int GetDeviceCaps(HDC hDC int nlndex); Folosind funcția GetDeviceCaps, o aplicație obține informații specifice despre un dispozitiv grafic, cum ar fi formatul cadru tampon, capabilitățile de procesare a culorilor, rezoluția, paleta, dimensiunile fizice, dimensiunile marginilor, suprapunerea alfa și suportul de umplere cu gradient, suport ICM (Image Color Management), și despre posibilitățile și limitările DDI Majoritatea caracteristicilor nu prezintă interes pentru programele de aplicație; acestea sunt doar linii directoare care guvernează modul în care motorul grafic interacționează cu driverul dispozitivului Unele marcaje vizează driverele de dispozitiv grafic pe biți utilizate în Windows , Windows și Windows De exemplu, marcajul CC ELLIPSES dintr-o solicitare CURVECAPS indică dacă driverul de dispozitiv poate desena o elipsă Windows NT/ DDI nu are acest indicator deoarece toate curbele eliptice sunt convertite în curbe Bezier înainte de a fi transmise la driverul de dispozitiv Când o aplicație interogează indexul CURVECAPS, Windows NT/ returnează un răspuns standard pentru a nu sparge aplicațiile vechi În tabel listează indecșii și valorile returnate ale funcției GetDeviceCaps Când este afișat, apelarea GetDeviceCaps oferă informații foarte importante despre dacă contextul dispozitivului acceptă paleta hardware Un program care redă într-un context activat pentru paletă trebuie să creeze o paletă logică, să o selecteze în contextul dispozitivului înainte de a începe randarea și să proceseze mesajele asociate paletei Capitolul Abstracția dispozitivului grafic Tabelul GetDeviceCaps: indexuri și valori returnate (Windows NT/ ) Exemplu de index Valoare și semnificație returnate DRIVERVERSION x Versiune driver; biți în formatul OxXYZZ, unde X este versiunea majoră a sistemului de operare, Y este versiunea minoră a sistemului de operare și ZZ este numărul versiunii driverului Informații raportate de șofer TEHNOLOGIE DTRASDISPLAY Informații raportate de șofer DT PLOTTER - pentru plottere, DT RASDISPLAY - pentru adaptoare video raster, DT RASPRINTER - pentru imprimante raster, DT RASCAMERA - pentru camere raster, DT CHARSTREAM - pentru fluxuri de caractere HORSIZE Lățimea suprafeței fizice în milimetri Ecranul afișează o valoare aproximativă Informații raportate de șofer VERSIZE Înălțimea suprafeței fizice în milimetri Ecranul afișează o valoare aproximativă Informații raportate de șofer HORZRES Lățimea suprafeței fizice în pixeli Informații raportate de șofer VERTRES Înălțimea suprafeței fizice în pixeli Informații raportate de șofer BITSPIXEL , , , Numărul de biți adiacenți din fiecare plan de culoare Informații raportate de șofer PLANURI Număr de planuri de culoare Informații raportate de șofer NUMBRUSHES - Numărul de perii pentru dispozitiv NUMPENS - Număr de stilouri pentru dispozitiv Pentru plottere, numărul de stilouri fizice NUMFONTS Număr de fonturi pentru dispozitiv NUMCOLORS - Numărul de articole din paleta dispozitivului sau - dacă nu există nicio paletă CURVECAPS Capacitățile de ieșire a curbei OxlFF Răspuns standard: CCCHORD CCCIRCLES|CC ELLIPSES|CC INTERIORS|CC PIE| CCROUNDRECT|CCSTYLED|CC WIDE|CCWIDESTYLED LINECAPS Capacități de ieșire de linie OxFE Răspuns standard: LC POLYLINE|LCMARKER|LC POLYMARKER|LC WIDE|LCSTYLED| LC WIDESTYLED|LCINTERIOARE Contextul dispozitivului Exemplu de index Valoare și semnificație returnate POLYGONALCAPS OxFF Capacități de ieșire Polygon Răspuns standard: PC POLYGON|PC RECTANGLE|PC WINDPOLYGON| PC SCANLINE PC WIDE | PC ȘTYLED | PC WIDESTYLED | PCJNTERIOARE Vă rugăm să rețineți: PC POLYPOLYGON și PC PATHS nu sunt incluse în răspunsul standard, dar acest lucru nu înseamnă că nu sunt acceptate de dispozitiv - a fost făcută doar o greșeală la raportarea capacităților TEXTCAPS x Abilitatea de a afișa șiruri de text Informații raportate de șofer CLIPCAPS Opțiuni de tăiere Răspuns standard: CP RECTANGLE Vă rugăm să rețineți că acest lucru nu înseamnă că dispozitivul nu poate clipi pe regiuni complexe RASTERCAPS x e Capacități raster Raportat parțial de șofer, preluat parțial din răspunsul standard: RC BITBLT RC BITMAP |RC GDI OUTPUT|RC DI BITMAP| RC DIBTODEV RC BIGFONT|RC STRETCHBLT|RC FLOODFILL| RC STRETCHDIB|RC OP DX OUTPUT ASPECTX Lățimea relativă a pixelilor dispozitivului între și Informații raportate de șofer ASPECTIE Înălțimea relativă a pixelilor dispozitivului în intervalul de la la Informații raportate de șofer ASPECTXY Diagonala relativă a pixelilor dispozitivului, Sqrt(ASPECTXX +ASCPECTYX ) Informații raportate de șofer LOGPIXELSX sau Rezoluția logică în puncte pe inch (dpi) pe lățime Informații raportate de șofer LOGPIXELSY sau Rezoluția logică în puncte pe inch (dpi) pentru înălțime Informații raportate de șofer SIZEPALETTE , sau Numărul de articole din paleta de sistem Valoarea este validă numai dacă RASTERCAPS conține indicatorul RCPALETTE NUMRESERVED sau Numărul de articole rezervate din paleta de sistem Valoarea este valabilă numai dacă RASTERCAPS conține indicatorul RC PALETTE Răspunsul este generat în funcție de setările sistemului COLORRES Numărul de biți în reprezentarea unui pixel Continuare Capitolul Abstracția dispozitivului grafic Tabelul Continuare Exemplu de index Valoare și semnificație returnate PHYSICALWIDTH Pentru dispozitivele de copiere pe hârtie, lățimea paginii fizice în unități de dispozitiv Informații raportate de șofer PHYSICALHEIGHT Pentru dispozitivele de copiere pe hârtie, înălțimea paginii fizice în unități de dispozitiv Informații raportate de șofer PHYSICALOFFSETX Pentru dispozitivele de copiere pe hârtie, lățimea marginii stângi care nu se imprimă în unități de dispozitiv Informații raportate de șofer PHYSICALOFFSETY Pentru dispozitivele de copiere pe hârtie, înălțimea marginii superioare care nu se imprimă în unități de dispozitiv Informații raportate de șofer SCALINGFACTORX Pentru dispozitive de copiere pe hârtie: factor de scalare pe axa x SCALINGFACTORY Pentru mașini de copiere pe hârtie: factor de scalare pe axa y VREFRESH Rata de reîmprospătare verticală pentru modul video curent Informații raportate de șofer DESKTOPHORZRES Lățimea desktopului în pixeli (diferită de lățimea unui singur ecran atunci când lucrați cu mai multe monitoare) DESKTOVERTRES Înălțimea desktopului în pixeli (diferită de înălțimea unui singur ecran atunci când lucrați cu mai multe monitoare) BLTALIGNMENT Aliniere preferată atunci când blitting pe un dispozitiv O valoare de zero înseamnă că dispozitivul utilizează accelerația hardware, astfel încât alinierea poate fi arbitrară Informații raportate de șofer SHADEBLENDCAPS Capabilități de suprapunere alfa și umplere în gradient Informații raportate de șofer COLORMGMTCAPS Capabilitati de gestionare a culorilor Informații raportate de șofer Înainte de a imprima pe un dispozitiv de hârtie, un program bine scris ar trebui să verifice întotdeauna dimensiunile exacte ale hârtiei și ale marginilor Rețineți că aplicația poate schimba orientarea paginii de la portret standard la peisaj; în același timp, lățimea și înălțimea foii, precum și marginile din stânga și de sus, sunt inversate Contextul dispozitivului Pentru aplicațiile care rulează sub Windows NT/ , verificarea capacităților grafice ale dispozitivului (CURVECAPS, LINECAPS, POLYGONCAPS, CLIPCAPS etc ) nu mai este la fel de importantă, deoarece motorul grafic ajută driverul dispozitivului în procesarea comenzilor grafice GDL atunci când este necesar Prin verificarea capabilităților contextului dispozitivului, o aplicație își poate optimiza și performanța De exemplu, dacă dispozitivul nu acceptă umpleri cu gradient, aplicația poate simula umplerea internă, simplifica sau elimina complet umplerile cu gradient Aplicațiile care rulează în moduri de biți și de culori pot folosi presetări grafice cu un număr redus de culori (în loc de de biți) Pe Windows NT/ , motorul grafic stochează mult mai multe informații despre dispozitiv decât pot fi obținute folosind funcția GetDeviceCaps care a fost destinată GDI pe biți Driverul dispozitivului grafic trebuie să ofere informații despre ieșirea liniilor de stil, numeroase opțiuni în tonuri de gri, suport pentru dispozitiv pentru spațiul de culoare CIE (Commission Internaționale de L'Eclairage) și unele capacități grafice interne De exemplu, motorul grafic ar putea avea nevoie de informații despre dacă un dispozitiv acceptă dreptunghiuri opace în textul de ieșire, dacă este acceptată spooling EMF, dacă dreptunghiurile de text opace pot fi umplute cu o perie personalizată, dacă coordonatele fracționale sunt acceptate în textul, dacă - Anti-aliasingul textului pe biți este acceptat, etc d TEHNOLOGIE DRIVERSION HORZSIZE x mm VERTSIZE HORZRES VERTRES LOGPIXELSX LOGPIXELSY BITSPIXEL PLANES NUMBRUSHES NUMPENS NUMMARKERS NUMFONTS NUMCOLORS PDEVICESIZE CURVECAPS LINECAPS mm pixeli pixeli dpi dpi de biți avioane -unu -unu -unu și urm fe Orez Obținerea de informații despre capacitățile unui dispozitiv grafic Capitolul Abstracția dispozitivului grafic Funcția GetDeviceCaps funcționează într-un mod elementar și nu necesită comentarii lungi În programul DEVICE, butonul GetDeviceCaps de pe pagina Display Devices deschide o casetă de dialog cu o listă a tuturor marcajelor dispozitivului (Figura ) Atribute în contextul dispozitivului Comenzile grafice GDI folosesc două tipuri de date - atribute care sunt comune diferitelor comenzi și valori care sunt specifice unei anumite comenzi Desigur, ar fi extrem de ineficient să ceri parametri și atribute comune care să fie specificate din nou și din nou într-un program Windows GDI stochează următoarele atribute în contextul dispozitivului: Despre sistemul de coordonate, modul de afișare și transformarea lumii; o Culoarea primului plan, culoarea fundalului, paleta și opțiunile de gestionare a culorilor; Despre parametrii de ieșire de linie; Despre parametrii pentru umplerea zonelor; Despre font, spațierea caracterelor și alinierea textului; Despre modul de scalare raster; Despre regiunea de tăiere; Despre o serie de alte atribute Fiecare atribut are un set de valori valide și o valoare implicită care este introdusă în contextul dispozitivului atunci când este creat Fiecare atribut definește de obicei o pereche de funcții API Win pentru a citi și a seta o nouă valoare pentru el În tabel enumeră atributele contextului dispozitivului, valorile implicite și funcțiile pentru a lucra cu acestea Tabelul Atributele contextului dispozitivului (Windows ) Atribut Valoare implicită Accesați funcții Mânerul de fereastră asociat NULL WindowFromDC (numai citire) Punct de bază de context GetDCOrgEx (numai citire) Raster Raster x GetCurrentObject, SelectObject (numai contexte de dispozitiv compatibile) Modul grafic GM COMPATIBLE GetGraphicsMode, SetGraphicsMode Modul de mapare MMTEXT GetMapMode, SetMapMode Dimensiuni viewport { } GetVi ewportExtEx, SetVi ewPortExtEx, ScaleViewportExtEx Punctul de bază al ferestrei de vizualizare { , } GetVi ewportOrgEx, SetVi ewportOrgEx, OffsetViewportOrgEx Contextul dispozitivului Atribut Valoare implicită Accesați funcții Dimensiunile ferestrei { } GetWindowExtEx, SetWindowExtEx, ScaleWindowExtEx Punctul de bază al ferestrei { , } GetWindowOrgEx, SetWindowOrgEx, OffsetWindowOrgEx Transformă identitatea Transform Matrix GetWorldTransform, SetWorldTransform, ModifyWorldTransform Culoare de fundal Culoarea de fundal a sistemului GetBkColor, SetBkColor Culoare text Negru GetTextColor, SetTextColor Palette DEFAULT PALETTE GetCurrentObject, EnumObjects, SelectPalette Ajustarea culorii GetColorAdjustment SetColorAdjustment Spațiu de culoare GetColorSpace, SetColorSpace Modul ICM SetICMMode Profil ICM GetlCMProfile, SetICMProfile Poziția actuală a creionului { , } GetCurrentPositionEx, MoveToEx, LineTo, BezierTo, Operație raster binar R C PYPEN GetR P , SetR P Mod de ieșire de fundal OPAQUE GetBkMode, SetBkMode Stilo logic BLACK PEN SelectObject, GetCurrentObject Pen Color DC GetDCPenColor, SetDCPenColor Direcția arcului GețArcDirection, SetArcDirection Limită unghiulară GetMiterLimit, SetMiterLimit Perie booleană WHITEBRUSH SelectObject, GetCurrentObject Culoarea pensulei DC GetDCBrushColor, SetDCBrushColor Punctul de bază al pensulei { , } GetBrushOrgEx, SetBrushOrgEx Modul de umplere poligon ALTERNATE GetPolyFillMode, SetPolyFillMode Continuare J Capitolul Abstracția dispozitivului grafic Tabelul Continuare Atribut Valoare implicită Accesați funcții Modul de scalare raster STRETCH ANDSCANS GetStretchBltMode, SetStretchBltMode Font boolean Font de sistem SelectObject, GetCurrentObject, GetCharW dth , GetKerningPairs, GetTextMetrics, Spațiere suplimentară dintre caractere GetTextCharacterExtra, SetTextCharacterExtra Înlocuirea fonturilor semnalizează SetMapperFlags Alinierea textului TA TOP|TA LEFT GetTextAl gn, SetTextAl gn Justificare text (justificat) { , } SetTextJust fi cat on (numai atribuirea) Layout GetLayout, SetLayout Calea BeginPath, ClosePath, EndPath, GetPath Regiunea de tăiere Zona client, întreaga suprafață a dispozitivului SelectObject, GetCl ipBox, GetClipRgn, SelectCli pRgn, ExcludeCl pRect, IntersectClipRect Metaregiunea GetMetaRgn, SetMetaRgn Dreptunghiuri de delimitare GetBoundsRect, SetBoundsRect Aceste atribute ale contextului dispozitivului vor fi discutate în detaliu mai jos Deocamdată, v-ați făcut doar o idee generală a cantității de informații stocate într-un context de dispozitiv Tabelul listează atributele contextului dispozitivului care sunt acceptate în Windows Lista include aproape toate atributele acceptate pe diferite platforme Windows Majoritatea atributelor au fost moștenite din API-ul Windows pe biți Unele atribute (cum ar fi transformările coordonatelor mondiale) sunt complet acceptate numai pe Windows NT/ Windows și Windows au introdus o serie de atribute noi, cum ar fi peria DC, creionul DC și atributele ICM În programul DEVICE, butonul DC Attributes de pe pagina Display Devices invocă o casetă de dialog pentru a lista toate atributele de context disponibile (Figura ) Această casetă de dialog oferă mai multe opțiuni pentru obținerea unui handle de context al dispozitivului În special, programul poate crea un context nou cu funcția CreateDC sau poate obține contexte de dispozitiv asociate cu diferite ferestre Contextul dispozitivului Orez Atributele contextului dispozitivului Asocierea unui context de dispozitiv cu o fereastră Contextul dispozitivului creat de funcția CreateDC poate fi gândit ca o suprafață grafică care se întinde pe întreaga zonă a dispozitivului - întregul ecran pentru dispozitivele de afișare sau întreaga pagină pentru imprimante Cu toate acestea, funcția CreateDC nu oferă o modalitate standard de a obține un context de dispozitiv într-un mediu Microsoft Windows și este de obicei utilizată numai atunci când lucrați cu dispozitive de copiere pe hârtie (cum ar fi imprimante) Ieșire grafică într-un mediu cu mai multe ferestre Ieșirea grafică este concentrată în primul rând pe ecranul monitorului, o resursă partajată de mai multe aplicații de pe sistemul de operare Windows Aplicațiile Windows obișnuite rulează în modul ferestre, ceea ce restricționează ieșirea fiecărei aplicații la o anumită porțiune a ecranului Fereastra este de obicei dreptunghiulară, iar parametrii ei sunt specificați atunci când este apelată funcția CreateWindow Cu toate acestea, sistemul de operare vă permite să creați o fereastră de formă arbitrară - sub forma unui dreptunghi cu colțuri rotunjite, o elipsă sau un poligon Pentru a schimba forma unei ferestre, tot ce trebuie să faceți este să creați un obiect regiune și să treceți mânerul acestuia la funcția SetWindowRgn Regiunea este specificată în coordonatele ecranului în raport cu punctul de bază al ferestrei Mai jos este un exemplu simplu de creare a unei ferestre obișnuite și apoi convertirea acesteia într-o formă eliptică Capitolul Abstracția dispozitivului grafic const TCHAR szProgram □ = T("Regiunea ferestrei"); const TCHAR szRectWin [] = T("Fereastra dreptunghiulara"); const TCHAR szEptcWin [] = T(„Fereastra eliptică”); int WINAPI WinMain(HINSTANCE hlnstance HINSTANCE, LPSTR, int) { HWND hWnd = CreateWindow( T("EDIT"), NULL, WS-FEREASTRĂ SUPREPUTĂ, , , GetDesktopWindowO, NULL, hlstance, NULL); ShowWindow(hWnd SW SHOW); SetWindowText(hWnd, szRectWin); MyMessageBox(NULL, szRectWin, szProgram, MB K); HRGN hRgn = CreateEllipticRgn(O, , , ): SetWindowRgn(hWnd, hRgn, TRUE); SetWindowText(hWnd, szEptcWin); MessageBox(NULL, szEptcWin, szProgram, MB OK); DestroyWindow(hWnd); întoarce ; } Pe fig prezintă două ferestre: obișnuită dreptunghiulară și eliptică O fereastră dreptunghiulară (stânga) are chenarul și bara de titlu obișnuită pentru ferestrele de nivel superior, în timp ce o fereastră eliptică are o chenar și o bară de titlu care sunt tăiate la limitele regiunii eliptice ^ Fereastră dreptunghiulară Fereastra tlliptic Orez Ferestre de diverse forme NOTĂ - - Ferestrele non-dreptunghiulare și zonele dedicate non-client sunt considerate o nouă tendință în proiectarea interfeței cu utilizatorul aplicației Windows Când sunt afișate în ferestre netradiționale, sunt utilizate regiuni care sunt definite folosind imagini raster sau vectoriale Procesarea mesajelor non-client înlocuiește procesarea standard a zonei non-client Contextul dispozitivului Mai multe ferestre care sunt pe ecran în același timp se pot suprapune În vechea implementare a Microsoft Windows, ferestrele din față blocau complet sau parțial ferestrele din spate, deși în cea mai recentă implementare a Windows , Microsoft tinde să interpreteze ferestrele ca obiecte de afișare care pot fi combinate folosind diferiți operatori Ca urmare a suprapunerii, fiecare fereastră are un alt atribut important - partea vizibilă Fereastra este împărțită în două părți: client și non-client Partea non-client include cadrul, bara de titlu, bara de meniu, barele de instrumente, barele de defilare și alte elemente de serviciu Zona client se referă la întreaga zonă a ferestrei care nu este inclusă în zona non-client - de regulă, aceasta este o zonă dreptunghiulară în mijlocul ferestrei Ieșirea în zona non-client este de obicei furnizată de funcția de fereastră standard, DefWindowProc, furnizată de modulul de ferestre (user dll) DefWindowProc are acces la stilul ferestrei, textul ferestrei, informațiile de focalizare și alte date necesare pentru a desena zona non-client În cele mai multe cazuri, aplicația utilizator oferă rezultate pe partea client a ferestrei În mediile multitasking precum Windows, starea ecranului este instabilă În orice moment, o aplicație poate apela o fereastră de timp, poate afișa informații și poate înceta să existe Aplicațiile care continuă să ruleze sunt singurele responsabile pentru restabilirea ecranului la normal În acest caz, sistemul de operare trimite mesaje către Windows a căror imagine a fost coruptă pentru a solicita o redesenare Receptorul de fereastră nu știe ce s-a întâmplat pe ecran, așa că trebuie să i se spună exact cum trebuie redesenată o parte a imaginii În caz contrar, redesenarea întregii ferestre va risipi resurse prețioase Următorii sunt factori pe care contextul dispozitivului trebuie să ia în considerare atunci când este afișat într-o fereastră О Punctul de bază este colțul din stânga sus al ferestrei О Dimensiuni - lățimea și înălțimea ferestrei O regiune Window este un subset al zonei dreptunghiulare definite de punctul de bază și dimensiunile ferestrei (pentru ferestre netradiționale) О Vizibilitate - numai partea vizibilă (nu suprapusă) a regiunii ferestrei este redesenată O fereastră întreagă sau zonă client - Aplicația dorește să ofere randare specializată zonei non-client sau este interesată doar de zona client? O zonă Actualizată este partea din fereastră care chiar trebuie actualizată Obținerea contextului dispozitivului asociat cu o fereastră Funcția CreateDC împiedică o aplicație să creeze un context de dispozitiv asociat cu o anumită fereastră API-ul Win oferă mai multe funcții pentru crearea de contexte de dispozitiv asociate cu Windows: Capitolul Abstracția dispozitivului grafic HDC GetWindowDC(HWND hWnd); HDC GetDC(HWND hWnd): HDC GetDCEx(HWND hWnd, HRGN hrgnClip, steaguri DWORD); HDC BeginPaint(HWND hWnd LPPAINTSTRUCT IpPaint); Funcția GetWindowDC returnează un context de dispozitiv pregătit pentru afișare în întreaga fereastră, inclusiv bara de titlu, meniuri și bare de defilare Punctul de bază al contextului dispozitivului este același cu punctul de bază al ferestrei Funcția GetDC returnează un context de dispozitiv care este redat numai în limitele părții client a ferestrei Punctul de bază al contextului dispozitivului este același cu punctul de bază al zonei client Nici GetWindowDC, nici GetDC nu respectă steagurile de stil WS CLIPCHILDREN și WSJCLIPSIBLINGS Cu alte cuvinte, mânerele pe care le returnează permit tragerile peste ferestrele copiilor și ale fraților După ce rezultatul este complet, contextul dispozitivului trebuie returnat sistemului de operare Funcția ReleaseDC eliberează resursele asociate cu handle-ul de context al dispozitivului obținut prin apelarea GetWindowDC, GetDC sau GetDCEx Un apel la Begi nPaint trebuie să fie asociat cu un apel asociat la EndPaint Contextul dispozitivului conține o serie de parametri care reflectă asocierea acestuia cu o anumită fereastră Funcția WindowFromDC returnează mânerul ferestrei cu care este asociat contextul dat Punctul de bază al contextului dispozitivului returnat de funcția GetDCOrgEx, care este întotdeauna { , } pentru contextele create de funcția CreateDC, conține coordonatele ecranului punctului de bază al ferestrei sau al zonei sale client Pe lângă aceste atribute documentate doar pentru citire, contextul dispozitivului conține o serie de câmpuri nedocumentate În special, contextul dispozitivului stochează punctul de bază și dimensiunile ferestrei asociate contextului Vom numi acest dreptunghi dreptunghi de afișare, chiar dacă într-adevăr se referă doar la afișarea zonei de clienți a ferestrei (de unde numele său „oficial” ereiWindow) Informațiile despre partea vizibilă a regiunii ferestrei sunt stocate în obiectul regiune Dacă fereastra este complet vizibilă pe ecran, regiunea de context vizibilă este un dreptunghi care are aceeași dimensiune cu imaginea Dacă un colț al unei ferestre este acoperit de o altă fereastră, regiunea de context vizibilă se schimbă pentru a fi unirea celor două dreptunghiuri De exemplu, regiunea vizibilă a unui context de dispozitiv returnat de funcția GetWindowDC poate cuprinde două dreptunghiuri: { , , , } și { , , , } Rețineți că valoarea atributului regiunii vizibile este setată înainte de a reveni de la GetWindowDC sau GetDC, dar atributul continuă să fie actualizat de sistemul de operare pe măsură ce alte ferestre sunt create și distruse, acordă focalizare, redimensionează sau repoziționează pe ecran Această abordare asigură că asocierea mânerului de context al dispozitivului cu o anumită fereastră este păstrată fără să vă faceți griji cu privire la modificările atributelor ferestrei Dacă fereastra are o regiune de fereastră personalizată atribuită de funcția SetWindowRgn (o elipsă în exemplul de mai sus), atunci regiunea vizibilă a contextului dispozitivului este subsetul vizibil al intersecției regiunii ferestrei cu dreptunghiul ferestrei Cu alte cuvinte, regiunea vizibilă a contextului dispozitivului include doar acei pixeli care îi satisfac pe toți Contextul dispozitivului trei condiții - sunt incluse în regiunea ferestrei atribuită de funcția SetWindowRgn, aparțin dreptunghiului ferestrei și sunt vizibile În exemplul nostru de fereastră eliptică, regiunea vizibilă constă din zeci de dreptunghiuri sau, pentru a fi mai precis, zeci de structuri SCAN, care sunt folosite pentru a reprezenta regiuni mai eficient în Windows NT/ O a treia modalitate de a obține contextul dispozitivului asociat cu o anumită fereastră este cu funcția GetDCEx Funcția GetDCEx ia doi parametri suplimentari, în comparație cu GetDC sau GetWindowDC, obiectul regiune și steag Deși documentația Microsoft afirmă că regiunea definește regiunea de tăiere, nu este aceeași cu regiunea de tăiere pe care o controlează aplicația folosind funcțiile SelectClipRgn și ExtSel ectCl pRgn Deoarece MSDN Books Online nu menționează două steaguri importante ale funcției GetDCEx, vom enumera toate steaguri aici (Tabelul ) Tabelul GetDCEx steaguri Descrierea steagului DCXWINDOW Returnează contextul dispozitivului pentru dreptunghiul ferestrei (în loc de dreptunghiul zonei client) DCXCACHE Folosiți contextul dispozitivului din memoria cache a managerului de ferestre chiar dacă clasa de ferestre are set de indicatori de stil CS OWNDC sau CSCLASSDC DCX PARENTCLIP Utilizați dreptunghiul ferestrei părinte și regiunea vizibilă, ignorând steagurile de stil WS CLIPCHILDREN și CS PARENTDC ale ferestrei părinte DCX CLIPSIBLINGS Excludeți toate regiunile ferestrei adiacente din regiunea vizibilă DCX CLIPCHILDREN Excludeți toate regiunile ferestrei copil din regiunea vizibilă DCX NORESETATTRS Nu resetați atributele contextului dispozitivului la valorile implicite DCX LOCKWINDOWUPDATE Ignorați o blocare de actualizare setată de funcția LockWindowUpdate DCX EXCLUDERGN Excludeți regiunea specificată de parametrul hrgnCHp din regiunea vizibilă DCXJNTERSECTRGN Construiți o nouă regiune vizibilă ca intersecție a regiunii specificate de parametrul hrgnCHp cu regiunea vizibilă curentă DCXEXCLUDEUPDATE Excludeți regiunea ferestrei care este actualizată din regiunea vizibilă DCXJNTERSECTUPDATE Construiți o nouă regiune vizibilă ca intersecția regiunii care este actualizată cu regiunea vizibilă curentă DCXVALIDATE Faceți conținutul ferestrei valid - cu alte cuvinte, resetați regiunea care este actualizată x Indicator nedocumentat care face automat apelul GetDCEx să reușească Capitolul Abstracția dispozitivului grafic Cu atât de multe steaguri, GetDCEx poate fi folosit pentru a înlocui alte funcții Să presupunem că un apel către GetDCExChWnd, NULL, DCX WINDOW|DCX NORESETATTRS) înlocuiește cu ușurință GetWindowDC(hWnd), iar un apel către GetDCExChWnd, NULL, DCXNORESETATTRS) înlocuiește GetDC(hWnd) Cu ajutorul unor steaguri suplimentare, puteți împiedica sistemul să folosească un context de dispozitiv aparținând unei ferestre sau unei clase și, de asemenea, să excludeți ferestrele vecine și secundare din regiunea vizibilă În plus, funcția GetDCEx vă permite să modificați regiunea vizibilă folosind un parametru suplimentar - regiune sau regiunea de actualizare a ferestrei și chiar să resetați datele regiunii de actualizare ale ferestrei Am ajuns la ultima modalitate de a crea un context de dispozitiv asociat cu o anumită fereastră Funcția BeginPaint returnează contextul dispozitivului pentru a gestiona mesajul WM PAINT Luând în considerare BeginPaint numai în ceea ce privește contextul returnat, acesta poate fi implementat după cum urmează: HDC BeginPalntOCHWND hWnd LPPAINTSTRUCT IpPaint) { steaguri DWORD = ; if ( GetWindowLong(hWnd, GWL STYLE) & WS CLIPCHILDREN) steagurile |= DCX-CLIPCHILDREN; Dacă ( GetWindowl ong(hWnd GWL STYLE) & WS CLIPSIBLINGS) semnalizatoare |= DCX-CLIPSIBLINGS: returnează GetDCExChWnd NULL, steaguri | DCXJNTERSECTUPDATE | DCX-VALIDATE); } Funcția BeginPaint verifică stilul ferestrei și determină dacă ferestrele secundare și adiacente ar trebui excluse din regiunea vizibilă, apoi determină intersecția regiunii vizibile cu regiunea ferestrei care este actualizată Conținutul ferestrei este declarat valid, adică regiunea actualizată este resetată Flag-urile DCX CACHE și DCX NORESETATTRS nu sunt folosite în acest caz, așa că funcția GetDCEx trebuie să verifice stilul ferestrei și să afle ce să facă în această situație Cu toate acestea, implementarea reală a BeginPaint rezolvă alte probleme De exemplu, dacă marcajul se află în regiunea care poate fi desenată, BeginPaint îl ascunde pentru a preveni ștergerea indicatorului Funcția BeginPaint trimite un mesaj WM ERASEBKGND către handlerul de mesaje al ferestrei Dacă aplicația procesează acest mesaj, are posibilitatea de a afișa un fundal solid sau bitmap Dacă mesajul este transmis funcției standard DefWindowProc a ferestrei și clasa ferestrei are o perie pentru a picta fundalul, atunci acea perie este folosită pentru a șterge regiunea de redesenare În plus, funcția BeginPaint trebuie, de asemenea, să umple structura PAINTSTRUCT cu mânerul contextului dispozitivului creat, dreptunghiul de delimitare al regiunii care urmează să fie redesenată și câteva steaguri Probabil înțelegeți diferența dintre un context de dispozitiv asociat cu o anumită fereastră și un context de dispozitiv creat de funcția CreateDC Principala diferență este că primul atribut include dreptunghiul de ieșire, care este un subset al suprafeței Contextul dispozitivului dispozitive și fereastra de vizualizare combinată, care este construită pe baza unor factori precum regiunea ferestrei, tăierea ferestrelor secundare și vecine, ferestrele de vizualizare și regiunea ferestrei care este actualizată Contextul general al dispozitivului O altă întrebare care duce adesea la confuzie trebuie să fie răspunsă: de unde provin contextele dispozitivului returnate de funcțiile GetDC, GetWindowDC, GetDCEx și BeginPaint? Pe vremuri, sistemul de operare Windows rula în modul real pe computere cu KB de memorie Contextul dispozitivului, care ocupa aproape de octeți de memorie, a fost considerat o structură mare, iar crearea unui context de dispozitiv cu încărcarea unui driver, găsirea punctelor de intrare și setarea atributelor pe computerele de MHz a fost destul de lentă Motorul de ferestre (USER) a numit funcția CreateDC de cinci ori și a creat un cache cu cinci contexte de dispozitiv Funcțiile GetDC, GetWindowDC și BeginPaint au preluat pur și simplu contexte gata făcute din cache Aplicațiile au fost obligate să elibereze mânerele de context de dispozitiv de îndată ce au terminat de redare, astfel încât alte aplicații să le poată folosi Pe versiunile de Windows pe biți, lipsa unui context liber în cache a cauzat eșecul ieșirii aplicației Un context de dispozitiv normal preluat din memoria cache de context se numește context de dispozitiv comun Limita de context de cinci dispozitive se aplică numai implementărilor Windows pe biți Windows , , NT și nu mai au această limitare Dacă sistemul rămâne fără contexte de dispozitiv stocate în cache, creează și folosește un context nou În acest domeniu, Windows NT/ diferă de Windows / Implementarea Windows NT/ se bazează pe o arhitectură completă pe de biți, fiecare proces rulând în propriul spațiu de adrese În timp ce majoritatea resurselor GDI sunt partajate la nivel de sistem, mânerele obiectelor GDI sunt legate de procese specifice; aceasta înseamnă că un context de dispozitiv poate fi utilizat numai de procesul care a creat contextul de dispozitiv Windows și se bazează pe o implementare GDI îmbunătățită pe biți care mută structuri mari de date (cum ar fi contextele dispozitivului) într-un heap separat de megaocteți Pentru comparație, merită remarcat faptul că pe versiunile pe biți de Windows, dimensiunea heap-ului GDI este de KB Contextul clasei dispozitivului Indicatorul CS CLASSDC din câmpul de stil al structurii WNDCLASS îi spune modulului de ferestre să creeze un context de dispozitiv pentru această clasă, care este partajat de toate ferestrele din clasă Un astfel de context se numește context dispozitiv de clasă Un context de clasă este creat atunci când este creată prima instanță a unei ferestre a unei clase date și este inițializat cu valori implicite Capitolul Abstracția dispozitivului grafic Apelarea funcțiilor GetDC, GetWindowDC și BeginPaint pe o fereastră din această clasă returnează contextul dispozitivului asociat cu clasa ferestrei cu dreptunghiul de ieșire actualizat, regiunea vizibilă și zona de tăiere goală Toate celelalte atribute ale contextului clasei (pen logic, culoarea textului, modul de afișare etc ) își păstrează valorile anterioare Când rezultatul este complet, funcția ReleaseDC sau EndPaint returnează contextul dispozitivului în clasă fără a-l distruge sau a reseta atributele Contextul clasei dispozitivului este distrus numai atunci când ultima fereastră a clasei este distrusă Dacă ați citit undeva că puteți omite apelurile ReleaseDC și EndPaint pentru un context de clasă de dispozitiv pentru că oricum nu fac nimic, uitați de asta Un astfel de sfat este dăunător; de dragul unui profit nesemnificativ, puteți avea probleme mari Apropo, EndPaint este cel care restaurează indicatorul care este ascuns atunci când este apelat BeginPaint Contextele dispozitivelor de clasă sunt utile pentru ferestrele de control care sunt redate cu aceleași atribute, deoarece acest lucru reduce timpul necesar pentru pregătirea contextului pentru randare și eliberarea acestuia Alte beneficii ale contextelor de clasă de dispozitive includ economisirea memoriei În zilele noastre, contextele clasei de dispozitive sunt acceptate pentru interoperabilitate Beneficiile lor devin nesemnificative pe fondul creșterii vitezei de memorie și a procesorului, precum și a arhitecturii Win pentru spațiul de adrese protejat Contextele clasei dispozitivului nu sunt recomandate pentru utilizare în programarea Win Contextul dispozitivului privat Indicatorul CS OWNDC din câmpul de stil al structurii WNDCLASS spune modulului de ferestre că ar trebui creat un context de dispozitiv separat pentru fiecare fereastră creată pe baza acestei clase Astfel, fiecare fereastră este asociată cu un context special al dispozitivului de-a lungul ciclului său de viață Astfel de contexte de dispozitiv sunt numite private Un context de dispozitiv privat este inițializat o singură dată cu valorile implicite Fiecare apel la GetDC, GetWindowDC și BeginPaint încarcă un context de fereastră privată cu un nou dreptunghi de randare și o regiune vizibilă Odată obținut contextul dispozitivului, aplicația își poate modifica atributele și poate executa comenzi grafice Funcțiile ReleaseDC și EndPaint returnează contextul dispozitivului în fereastră fără a-l schimba, astfel încât data viitoare când este primit contextul, atributele acestuia (cum ar fi creionul și pensula) rămân aceleași Documentația MSDN descrie contextele dispozitivelor private într-un mod vag (consultați secțiunea Contexte dispozitive private de afișare) Mai exact, prevede că o aplicație ar trebui să primească un handle de context privat o singură dată și să-l folosească în mod repetat și că o aplicație poate include regiunea care urmează să fie actualizată în procesarea unui mesaj WM PAINT folosind funcția BeginPaint Contextele dispozitivelor private oferă performanță maximă cu prețul consumului maxim de memorie Contextul dispozitivului utilizează trei tipuri de resurse - mânerul GDI, memoria în spațiul de adrese al aplicației utilizator și memoria în spațiul de adrese al nucleului Contexte închise Contextul dispozitivului dispozitivele au sens doar pentru ferestrele cu atribute complexe care necesită mult timp pentru a fi pregătite și pentru ferestrele care trebuie reîmprospătate frecvent Se recomandă utilizarea contextelor private numai în acele cazuri în care factorul de performanță este mult mai important decât costurile crescute de memorie și resurse GDI Contextul dispozitivului părinte Indicatorul CS PARENTDC nu are legătură cu problema pe care încearcă să o rezolve contextele dispozitivelor private și de clasă Când acest indicator este setat, funcția GetDC sau BeginPaint pentru o fereastră copil utilizează dreptunghiul de ieșire și regiunea vizibilă a ferestrei părinte pentru a pregăti contextul dispozitivului; de aceea aceste contexte de dispozitiv sunt numite părinte Contextul dispozitivului părinte este stocat în cache, astfel încât atributele sale sunt inițializate la valorile implicite Diferența este că contextul dispozitivului părinte moștenește dreptunghiul de afișare și regiunea de vizualizare a ferestrei părinte, ceea ce economisește timp calculând dreptunghiul de afișare și regiunea de vizualizare a ferestrei copil Indicatorul CS PARENTDC este luat în considerare doar în cazul simplu când o fereastră copil dorește să folosească parametrii ferestrei părinte la desen Este ignorată în situațiile în care fereastra părinte folosește un context de dispozitiv privat sau de clasă, când fereastra părinte își decupează ferestrele copil și când o fereastră copil își decupează ferestrele secundare sau vecine Alte contexte de dispozitiv Până acum, ne-am limitat la contextele de dispozitiv create de funcția CreateDC și contextele asociate cu Windows Aceste două tipuri de contexte oferă un mijloc complet de lucru cu dispozitivul, adică vă permit să primiți informații și să trimiteți comenzi grafice la adaptorul video sau la imprimantă Există și alte varietăți de contexte de dispozitiv în mediul Windows, și anume contexte de informații, compatibilitate și metafișier Contextul informațiilor despre dispozitiv Uneori, nevoile unei aplicații sunt limitate la simpla obținere a atributelor unui dispozitiv grafic De exemplu, la încărcarea unui document, un editor de text trebuie să solicite unei imprimante standard dimensiunile hârtiei și ale marginilor pentru a formata corect documentul în stil WYSIWYG În aceste situații, Windows vă permite să creați un context de dispozitiv trunchiat numit context informațional Contextul informațional este creat de funcția CreatelC: HDC CreateIC(LPCTSTR pszDriver, LPCTSTR pszDevice, LPCTSTR pszOutput, CONST DEVMODE *pdvmlnist): Capitolul Abstracția dispozitivului grafic Funcția CreatelC este similară cu CreateDC, dar este mai rapidă și utilizează mai puțină memorie Încercările de a reprezenta un grafic pe mânerul de context info returnat de CreatelC sunt pur și simplu ignorate Contextul informațional este șters de funcția DeleteDC (nu există nicio funcție DeleteIC) Context dispozitiv compatibil Contextul dispozitivului ar trebui să ofere o interfață de aplicație independentă de dispozitiv cu dispozitive grafice Cu toate acestea, contextele de dispozitiv returnate de funcțiile de mai sus permit doar afișarea graficelor pe dispozitive fizice, cum ar fi adaptoare video și imprimante Funcționarea acestor dispozitive este asigurată de drivere care primesc comenzi de nivel scăzut de la motorul grafic Dar, în unele situații, poate fi foarte convenabil să scoateți pe un dispozitiv grafic care este simulat în memorie ca bitmap Un context de dispozitiv compatibil (contextul dispozitivului de memorie) vă permite să randați pe bitmap-ul asociat sau să copiați un bitmap pe suprafața altui dispozitiv grafic HDC CreateCompatibleDC(HDC hDC): Parametrul hDC specifică un context de dispozitiv existent cu care contextul creat trebuie să fie „compatibil” Un context de dispozitiv compatibil folosește un bitmap ca suprafață grafică În mod implicit, atunci când se creează un context compatibil, acest raster constă dintr-un pixel Win conține funcții pentru crearea rasterelor și asocierea acestora cu o suprafață (funcția SelectObject) Contextele compatibile sunt șterse cu funcția DeleteDC Un context compatibil moștenește multe atribute din contextul său de „referință” Mai mult, pentru un context compatibil, funcția GetDeviceCaps returnează aceleași rezultate ca și pentru contextul de referință Un context de dispozitiv compatibil cu indicatorul DT RASPRINTER în atributul TEHNOLOGIE poate încurca o funcție care funcționează atât cu contexte de dispozitiv compatibile, cât și cu cele obișnuite Contextele dispozitivelor compatibile sunt o caracteristică foarte utilă Le vom acoperi în detaliu în Capitolul , când vom descrie rasterele dependente de dispozitiv (DDB) și secțiunile DIB Contextul dispozitivului metafile Un alt tip de context care nu corespunde unui dispozitiv fizic real este contextul dispozitivului metafișier Un context compatibil vă permite să generați un raster folosind comenzile grafice GDI; Contextul dispozitivului metafișier permite stocarea comenzilor GDI ca flux de date sau fișier disc, care este apoi redat ca un clip audio sau video Principala diferență dintre aceste tipuri de contexte este că un context compatibil pentru stocarea rezultatelor de ieșire creează un raster cu o dimensiune și rezoluție fixe, în timp ce un context metafișier Contextul dispozitivului stochează comenzi vectoriale și raster, care sunt apoi scalate cu precizie la diferite dimensiuni Contextele dispozitivului metafile sunt create de două funcții O funcție generează metafișiere Winl , iar cealaltă generează metafișiere Win extinse: HDC CreateMetaFile(LPCTSTR IpszFIle): HDC CreateEndMetaF e(HDC hdcRef LPCTSTR IpszFIleName, CONST RECT * IpRect LPCTSTR IpDescription); Atât metafișierele Windows (metafișiere Winl ), cât și metafișierele extinse sunt utilizate pe scară largă în aplicațiile comerciale pentru stocarea imaginilor clipate (cliparts) Metafișierele extinse sunt, de asemenea, o parte importantă a spooling-ului Windows , , NT și Capitolul al acestei cărți este dedicat metafișierelor Pentru a recapitula, un context de dispozitiv este un concept convenabil utilizat de API-ul Windows pentru a oferi rezultate grafice independente de dispozitiv În această secțiune, ne-am familiarizat cu diferite clase de contexte de dispozitiv, am analizat cum să le creăm, atributele și metodele de lucru cu atribute În tabel Figura oferă un rezumat al diferitelor contexte ale dispozitivului și al caracteristicilor acestora Tabelul Un rezumat rapid al contextelor dispozitivului Tip de context Creare, Aplicare distrugere Context generic al dispozitivului CreateDC, DeleteDC Acces complet la suprafața dispozitivului, dispozitive de afișare primară și secundară, oglindire și copiere pe hârtie Contextul dispozitivului asociat cu fereastra GetWi ndowDC, GetDC, GetDCEx, BeginPaint, EndPaint, ReleaseDC Desenați în porțiunea suprafeței ecranului corespunzătoare regiunii vizibile a ferestrei sau zonei sale client, excluzând regiunile ferestrelor copil și învecinate Contextul dispozitivului returnat de funcția BeginPaint restricționează zona de ieșire la partea care este inclusă în regiunea ferestrei care este actualizată Contextele de acest tip sunt împărțite în obișnuite, de clasă, private și părinte Contextul informațiilor CreatelC, DeleteDC Obținerea de informații despre capabilitățile dispozitivului și driverului Context compatibil CreateCompati bleDC, DeleteDC Redare pe o suprafață bitmap din memorie și transmiterea imaginii către un alt context de dispozitiv Context metafișier CreateMetaFile, CreateEnhMetaFile, DeleteDC Scrierea comenzilor GDI într-un flux de date sau fișier și reluarea acestora Capitolul Abstracția dispozitivului grafic Reprezentarea formală a unui context de dispozitiv Secțiunea anterioară a descris diferitele tipuri de contexte de dispozitiv și atributele lor comune În această secțiune, vom face câteva clarificări la nivel conceptual pe baza informațiilor obținute din analiza noastră a implementării GDI în Windows Deci, contextul dispozitivului este o structură de date care îndeplinește două sarcini principale în sistemul grafic Windows În primul rând, contextul dispozitivului oferă o abstractizare independentă de dispozitiv, care permite afișarea graficelor pe diferite dispozitive grafice, atât fizice (de exemplu, un adaptor video), cât și logice (cum ar fi un metafișier) În al doilea rând, contextul dispozitivului stochează diverse setări și obiecte grafice utilizate de comenzile grafice Suprafața grafică de bază menținută de un context de dispozitiv este o matrice bidimensională de pixeli, adresabili individual și de citire/scriere Modelul de suprafață grafică este ideal pentru adaptoare video raster și imprimante, dar nu este universal Dispozitivele care nu sunt conforme cu acest model nu acceptă unele operațiuni grafice De exemplu, imprimantele compatibile cu PostScript permit ieșirea numai la suprafață, dar nu permit citirea conținutului acestuia, așa că ar fi dificil să implementați operații binare sau ternare pe imprimantele PostScript Un alt exemplu sunt contextele metafile, care nu vă permit să obțineți valoarea culorii unui pixel În mod normal, un context de dispozitiv menține o scriere pentru fiecare pixel de dispozitiv, deși imprimanta are probleme la imprimarea pixelilor la marginile foii; acesta este motivul pentru care contextul dispozitivului permite aplicației utilizator să obțină informații despre dimensiunea hârtiei Pentru a sprijini ieșirea în medii cu mai multe ferestre și cu mai multe sarcini, un context de dispozitiv poate fi asociat cu o fereastră Porțiunile de context în care este permisă ieșirea sunt determinate de o schemă destul de complexă controlată de modulul de ferestre Contextul dispozitivului folosește următoarele atribute pentru a determina subsetul de suprafață pe care este posibilă ieșirea О Dreptunghi fereastră Zona dreptunghiulară a suprafeței dispozitivului pe care se efectuează ieșirea Corespunde dreptunghiului de delimitare al ferestrei specificat la apelarea CreateWindow Toate mișcările și modificările dimensiunii ferestrei sunt urmărite automat de sistem și reflectate în dreptunghiul ferestrei de context Funcția GetDCOrgEx returnează poziția colțului din stânga sus al dreptunghiului ferestrei О Regiunea sistemului O regiune care se calculează luând în considerare mai mulți factori Inițial, regiunea de sistem este aceeași cu regiunea ferestrei, care este de obicei dreptunghiulară, dar poate fi, de asemenea, orice regiune specificată la apelarea SetWindowRgn Zonele ocupate de ferestre copil sau învecinate sunt excluse din regiunea sistemului dacă steagurile corespunzătoare sunt setate în stilul clasei de ferestre Apoi exclude toate zonele care sunt închise în ordinea z a ferestrelor de pe desktop Alte sisteme Reprezentarea formală a unui context de dispozitiv Noua regiune se intersectează cu regiunea de actualizare a ferestrei dacă funcția BeginPaint a fost folosită pentru a obține contextul dispozitivului Regiunea contextului sistemului urmărește automat toate mișcările ferestrelor și modificările în ordinea z Despre regiunea meta și regiunea de tăiere Subseturi de suprafețe ale dispozitivelor definite de aplicație la care ar trebui să apară ieșirea Când un context de dispozitiv este creat sau primit de la un windower, metaregiunea și regiunea de tăiere sunt întotdeauna resetate la starea completă a suprafeței dispozitivului Metaregiunile sunt slab documentate în API-ul Win ; oferă un nivel suplimentar de tăiere Există numeroase funcții în API-ul Wn pentru modificarea regiunii de tăiere într-un context de dispozitiv Despre regiunea Rao Intersecția precalculată a regiunii sistemului, a metaregiunii și a regiunii de tăiere Regiunea de sistem, metaregiunea și regiunea de clipare sunt stocate în câmpuri independente ale contextului dispozitivului, deși documentația sugerează că regiunea sistemului determină valoarea inițială a regiunii de clipare atunci când este obținut contextul dispozitivului Cu toate acestea, toate funcțiile de trasare funcționează numai la intersecția regiunii sistemului, a metaregiunii și a regiunii de tăiere Pentru ca această intersecție să nu fie recalculată cu fiecare apel grafic, motorul grafic o calculează în avans, o actualizează cu toate modificările din regiunea sistemului, metaregiunea și regiunea de tăiere și salvează rezultatul într-un câmp special Rezultatul se numește regiunea Rao, după un programator Microsoft pe nume Rao Remala, care, conform Undocumented Windows, a insistat să includă acest câmp în contextul dispozitivului Contextul dispozitivului este de obicei asociat cu driverul dispozitivului grafic, care este singurul responsabil pentru transmiterea comenzilor către dispozitivul grafic Interfața dintre motorul grafic și driverul dispozitivului grafic se numește DDI (Device Driver Interface) și este documentată în Microsoft DDK (Device Development Kit) Driverul de dispozitiv grafic oferă motorului grafic un tabel de funcții de apel indirect care implementează apeluri DDI Motorul grafic creează o structură logică a dispozitivului pentru a stoca informații despre driverul dispozitivului grafic Un driver de dispozitiv grafic poate exista în mai multe încarnări cu setări diferite, cum ar fi formatul pixelilor cadru tampon sau setările de imprimare Acest lucru permite comutarea dinamică a modurilor video și distribuirea simultană a mai multor lucrări Când este creată o instanță de driver de dispozitiv, i se trece o structură DEVMODE la cererea unui motor grafic sau a unei aplicații; driverul returnează două structuri cu informații despre atributele și capacitățile dispozitivului și driverului Motorul grafic stochează informațiile primite în structura dispozitivului fizic Driverul grafic își creează, de asemenea, propria sa structură de date și își transmite mânerul motorului grafic Structura dispozitivului fizic stochează o mulțime de informații despre șofer - dimensiuni, capacități, restricții, perii speciale de cursă, modele de semitonuri etc Capitolul Abstracția dispozitivului grafic Structura contextului dispozitivului conține indicatorii către structurile logice și fizice ale dispozitivului Structura dispozitivului fizic este preluată din informațiile returnate aplicației utilizator ca răspuns la o solicitare GetDeviceCaps În plus, structura fizică a dispozitivului spune motorului grafic cum ar trebui să fie împărțite comenzile grafice GDI în apeluri DDI deservite de driverul dispozitivului De exemplu, șoferul suportă curbele Bezier sau ar trebui să fie segmentate? Prin indicatorii către funcțiile de apel indirect din structura dispozitivului logic, motorul grafic merge la funcția care gestionează acest sau acel apel DDI Astfel, toate aspectele specifice hardware ale sistemului grafic Windows sunt încapsulate în aceste două structuri În plus, un context de dispozitiv include câmpuri care îl leagă la o fereastră, bitmap sau metafișier, precum și obiecte și atribute API Win Puteți lucra cu unele câmpuri folosind Win API, altele sunt parțial sau complet ascunse de aplicațiile utilizatorului Unele câmpuri sunt doar pentru citire (de exemplu, punctul de bază al contextului unui dispozitiv); altele sunt atât citibile, cât și inscriptibile Din motive de performanță, unele atribute ale contextului dispozitivului utilizate în mod obișnuit sunt stocate în spațiul de adrese ale utilizatorului, ceea ce facilitează recuperarea valorilor acestora fără a trece la și de la modul kernel Cu toate acestea, cea mai mare parte a contextului dispozitivului este stocată în spațiul de adrese în modul kernel în care funcționează motorul grafic și driverele de dispozitiv grafice normale GDI are o grijă deosebită pentru a proteja contextele dispozitivului, la fel ca și restul obiectelor GDI, care vor fi discutate în capitolul următor Când se creează un context, aplicația utilizator este furnizată doar cu mânerul său, prin care aplicația se referă la context atunci când apelează funcții GDI Având în vedere un handle de context de dispozitiv, GDI găsește o intrare de tabel de obiect GDI (vezi capitolul următor) care conține pointeri către ambele structuri de date de context (modul utilizator și modul kernel) Structura contextului dispozitivului în Windows este oarecum ilustrată în Figura În modul utilizator, contextul dispozitivului este reprezentat de o structură DCATTR care conține aproape toate atributele și obiectele utilizate de API-ul Win (cu excepția paletei, spațiului de culoare etc ) Modul Kernel folosește structura DCOBJ, care conține dreptunghiul ferestrei, regiunea de tăiere, regiunea sistemului (prgnVis în figură), regiunea Pao și alte regiuni Câmpul PPDEV conține un pointer către structura dispozitivului fizic, PDEV WIN K Câmpurile GDIINFO, DEVINFO și AHSURF ale structurii PDEV WIN K stochează informațiile primite de la driverul de dispozitiv Câmpul PLDEV conține un pointer către structura dispozitivului logic, LDEV WIN K Cea mai mare parte a structurii LDEV WIN K este ocupată de un tabel de de indicatori de funcție de apel indirect, APFN, care este, de asemenea, duplicat în structura PDEV WIN K Contextele dispozitivelor au multe în comun cu obiectele din sistemele orientate pe obiecte și limbaje precum C++ Diferitele atribute stocate în contextul dispozitivului corespund variabilelor de clasă, iar tabelul de funcții stocat profund în contextul dispozitivului este exact același cu tabelul de funcții virtuale dintr-un obiect C++ care conține funcții virtuale Conducător auto Exemplu: clasă generică de ferestre cadru Dispozitivul grafic asigură actualizarea contextului abstract prin implementarea funcțiilor DDI Odată ce contextul dispozitivului este pregătit corespunzător, aplicația funcționează cu acesta folosind setul standard de funcții fără a vă face griji cu privire la modul în care sunt implementate apelurile grafice dhpdev dctype ppdevnext flgraphics hsemdvlck paleta hsempointer — Pen boolean Spațiu de culoare spritestate Pen boolean hdcsave hlfntdefault ' Culoare de fundal Traiectorie ahsurf Culoare primară prgnClip devinfo Modul grafic prgnMeta gdiinfo Tabelul de obiecte GDI gor prgnAPI psurface Modul de umplere a fundalului prgnVis hspooler nextldev Mod de umplere a formei prgnRao ddglobal prevldev strchbltmode ercIWindow pgraphisdev levtype xform ppdev pdevmode cRefs hsem pldev pgdidrvinfo punctul de bază al ferestrei uldrvversion apfn[ ] apfn[ ] dcattr dcobj pdev win k Idev win k Orez Contextul dispozitivului Windows și structurile de date Figura nu este deloc exhaustivă Consultați Capitolul pentru mai multe informații sau faceți propria cercetare folosind fie WinDbg cu extensia de depanare GDI, fie programul Fosterer din Capitolul Capitolul prezintă un program care modifică tabelul de funcții GDI într-o structură PDEV WIN K pentru a urmări apelurile DDI Capitolul oferă un exemplu de implementare a interfeței DDI într-un driver de imprimantă Exemplu: clasă generică de ferestre cadru Începând de la acest capitol, funcționarea aproape tuturor primitivelor grafice GDI va fi explicată cu exemple specifice În aproape toate programele scrise mai devreme, interfața de utilizator a constat dintr-o casetă de dialog cu mai multe pagini cu file - acest lucru nu este în mod clar suficient pentru a demonstra API-ul GDI În această secțiune, vom dezvolta un set generic de clase pentru scrierea programelor Windows care îndeplinește următoarele condiții A Fereastra principală a programului are o bară de titlu, un meniu, un meniu de sistem și un cadru care poate fi tras pentru a redimensiona fereastra principală A Fereastra principală conține o bară de instrumente pentru acces rapid la comenzile utilizate frecvent Butoanele din bara de instrumente sunt furnizate cu hărți de biți vizuale și sfaturi cu instrumente Capitolul Abstracția dispozitivului grafic A Fereastra principală are o bară de stare împărțită în mai multe panouri A În restul ferestrei principale (zona client), programul poate afișa orice crede de cuviință În cele ce urmează, această zonă este numită „pânză” (pânză) Un program care implementează aceste cerințe este echivalent funcțional cu programul de bază generat de MFC Application Wizard cu Single Document Interface (SDI) selectată, document/vizualizare dezactivată și fără suport pentru baze de date și controale ActiveX Pentru a face biblioteca cu adevărat universală, aceasta include clase C++ care conțin funcții virtuale Toate clasele C++ din această carte încep cu prefixul „K”; acest lucru le permite să fie utilizate împreună cu clasele MFC care încep de obicei cu litera „C” Clasa din bara de instrumente Barele de instrumente sunt implementate de următoarea clasă: clasa KToolbar { HWND m hToolTip; UINT m ControlID; HINSTANCE m ResInstance: UINT m ResId; public: HWND m hWnd: KToolbarO { m hWnd = NULL: m hToolTip = NULL: m ControlID = : m ResInstance = NULL: m ResId = : } void Create(HWND hParent, HINSTANCE hlnstance UINT nControlID, const TBBUTTON * pButtons int nCount): void Resize(HWND hParent int lățime, int înălțime): }: Clasa KToolbar este foarte simplă, deci nu există funcții virtuale în ea Metoda principală a clasei, Create, preia o serie de definiții TBBUTTON, creează o fereastră copil din bara de instrumente cu butoane și o fereastră de tip tooltip Sfaturile cu instrumente corespund rasterelor de pe butoanele panoului Câmpul dwData al fiecărei definiții TBBUTTON stochează ID-ul resursei șir pe care metoda Create îl utilizează pentru a încărca șirul și a-l include în fereastra de prompt Metoda Redimensionare se modifică Exemplu: clasă generică de ferestre cadru redimensionează fereastra barei de instrumente pentru a se potrivi cu noua lățime a zonei client a ferestrei părinte Clasa bară de stare Fereastra barei de stare este, de asemenea, foarte simplă Declarația clasei KStatus-Window arată astfel: typedef enumerare { panou viol viol }: clasa KstatusWindow { public: HWND m hWnd; UINT m ControlID: KstatusWindowO { m hWnd = NULL: m ControlID = ; } void Create(HWND hParent UINT nControlID); void Redimensionare(HWND hParent Lățimea int Înălțimea int); void SetTextdntpane HINSTANŢĂ hlnst int messid intparam= ): void SetTextdntpane mesaj LPCTSTR): }: Metoda Create creează o fereastră bară de stare ca un copil al ferestrei principale Metoda Resize modifică lățimea ferestrei pentru a se potrivi cu lățimea părții client a ferestrei părinte și împarte bara de stare în trei panouri Cele două metode SetText sunt pentru afișarea mesajelor pe bara de stare clasă de pânză Clasa KCanvas descrie fereastra canvas în care au loc toate rezultatele principale ale aplicației Clasa KCanvas este derivată din clasa KWindow descrisă în Capitolul Conține patru funcții virtuale care pot fi suprascrise în clasele derivate clasa KstatusWindow: clasa KCanvas : KWindow public { public: virtual LRESULT WndProc(HWND hWnd UINT uMsg, WPARAM wParam LPARAM Param): virtual void OnDraw(HDC hDC const RECT * rcPaint): HINSTANŢĂ m hlnst; Capitolul Abstracția dispozitivului grafic public: virtual BOOL OnCommandCWPARAM wParam LPARAM Param): KStatusWindow * m pStatus: Kcanvas(): void SetStatus(HINSTANCE hlnst KStatusWindow * pStatus) { m hlnst=hlnst; m pStatus = pStatus: virtual -KCanvasO: Metoda virtuală WndProc procesează toate mesajele trimise către fereastra canvas Implementarea implicită gestionează mesajele WM CREATE și WM PAINT În timpul procesării mesajului WM PAINT, sunt apelate funcțiile BeginPaint, KCanvas: : nDraw și EndPaint Metoda OnCommand gestionează mesajele WM COMMAND trimise din fereastra principală Mai târziu, vom crea o clasă derivată din KCanvas care se va ocupa de mesajele de zoom și defilare Clasa de ferestre cu cadru Fereastra principală a programului este abstractizată ca clasa KFrame, de asemenea derivată din clasa KWindow În terminologia Windows, clasa KFrame implementează o fereastră cadru SDI (Single Document Interface), dar mai târziu vom deriva o clasă pentru a implementa ferestre cadru Multiple Document Interface (MDI) clasa KstatusWindow: clasa KCanvas: clasa KToolbar: clasa KFrame : public KWindow typedef enumerare { ID STATUSWINDOW = , ID TOOLBAR = }: KToolbar Kcanvas KstatusWindow * m pToolbar: * m pCanvas: *m pStare: const TBBUTTON int * m pButtons: m nButtons: int m nToolbarHeight: m nStatusHeight: virtual LRESULT WndProc(HWND hWnd UINT uMsg WPARAM wParam LPARAM Param): Exemplu: clasă generică de ferestre cadru virtual LRESULT OnCreate(void); virtual LRESULT OnSize (lățime int, înălțime int): virtual BOOL OnCommand(WPARAM wParam, LPARAM IParam): public: KFrame(HINSTANCE hlnstance, const TBBUTTON * pButtons, int nCount KToolbar * pToolbar, KCanvas * pCanvas, KStatusWindow*pStatus): virtual-KFrameO: }; Metoda virtuală WndProc asigură gestionarea principală a mesajelor din fereastră În timpul procesării mesajului WM CREATE, apelează metoda OnCreate, în timp ce procesează mesajul WM SIZE, apelează metoda OnSize și, în timp ce procesează mesajul WM COMMAND, apelează metoda OnCommand Nu există nimic de desenat în fereastra cadru principal, deoarece zona sa client este complet acoperită de ferestrele barei de instrumente, canvasului și barei de stare Cu toate acestea, constructorul KFrame: :KFrame( ) merită atenție Dorim ca această clasă să fie cât mai generică și reutilizabilă posibil, astfel încât instanțele KToolbar, KCanvas și KStatusWindow sunt create în afara clasei KFrame Pointerii către ele sunt transmise constructorului clasei KFrame împreună cu definițiile butoanelor din bara de instrumente Rețineți că puteți deriva o clasă din KCanvas și puteți transmite un pointer către aceasta în loc de un pointer către KCanvas Implementarea constructorului este extrem de simplă: pur și simplu salvează parametrii trecuți pentru utilizare ulterioară în OnCreate și alte metode Metoda OnCreate este singura metodă de clasă care conține cod real Apelează metode pentru a crea bara de instrumente, pânza și ferestrele barei de stare care au dimensiunea și poziția corectă LRESULT KFrame::OnCreate(void) { RECT rect: // Fereastra barei de instrumente este // în partea de sus a zonei client if ( m pToolbar ) { m pToolbar->Creare(m hWnd, mjilnst ID-STATUSWINDOW, m pButtons mjrButtons): GetWindowRect(m pToolbar->m hWnd, & rect): m nToolbarHeight = rect bottom - rect top: } el se mjTToolbarHeight = ; // Fereastra barei de stare este localizată // în partea de jos a zonei client Capitolul Abstracția dispozitivului grafic dacă (m pStatus) { m pStatus->Create(m hWnd, ID STATUSWINDOW); GetWindowRect(m pStatus- m hWnd & rect); mjiStatusHeight = rect bottom - rect top; } el se m nStatusHeight= : // Creați o fereastră canvas deasupra ferestrei barei de stare dacă ( m pCanvas ) GetCl entRect(m hWnd, & rect); m pCanvas->SetStatus(m hInst, m pStatus); m pCanvas->CreateEx(O, T(„Clasa Canvas”) NULL, WS VISIBLE | WS CHILD, mjiToolbarHeight rect right, rect bottom - m nToolbarHeight - mjrStatusHeight m hWnd, NULL, m hlnst); } întoarce ; } Programul verifică pointerii către toate obiectele fereastra copil și apelează metodele lor de creare numai dacă pointerul trece verificarea Drept urmare, niciuna dintre ferestrele copil nu este strict necesară - programul funcționează fără ele Sistemul de ferestre OS asigură că bara de instrumente ocupă partea de sus a zonei client, iar bara de stare este în partea de jos Apelarea CreateEx în fereastra pânzei ia în considerare acest lucru și ajustează poziția și înălțimea pânzei în consecință Implementarea implicită a KFrame: :OnSize asigură că cele trei ferestre secundare sunt poziționate și dimensionate corect atunci când fereastra principală este redimensionată Procesarea primară a comenzilor de meniu este efectuată prin metoda OnCommand În mod implicit, mesajul primit este transmis funcției KCanvas::OnCommand Programul de testare Principalul factor în evaluarea claselor de ferestre de cadru este comoditatea și versatilitatea lor în programare Vom lua în considerare doar cele mai interesante fragmente de programe, pentru a nu repeta același lucru iar și iar Programul de testare simplu de mai jos folosește toate cele patru clase de ferestre Programul creează o fereastră cu o bară de titlu, o bară de instrumente cu două butoane și sfaturi, o pânză și o fereastră cu bară de stare În comparație cu programul de bază MFC generat de expert, lipsesc multe aici, inclusiv macrocomenzi, variabile globale, alocare heap și apeluri DLL de sistem Exemplu: clasă generică de ferestre cadru const TBBUTTON tbButtons[] = { { STDJILENEW IDMJILE NEW TBSTATEJNABLED, TBSTYLE-BUTTON, { } IDSJILENEW, } {STDJ ELP IDM APP ABOUT,TBSTATEJNABLED TBSTYLE BUTTON, { } IDSJ ELPABOUT, } }: int WINAPI WinMain(HINSTANCE hlnst HINSTANCE, LPSTR IpCmd int nShow) { Bara de instrumente KToolbar: Pânză Kcanvas: Stare KStatusWindow; Cadrul KMyFrame(hlnst, tbButtons, & bara de instrumente, & pânză, & stare): frame CreateEx(O, T("ClassName"), T("Program Name"), WS OVERLAPPEDWINDOW, CWJJSEDEFAULT, CWJJSEDEFAULT, CWJJSEDEFAULT, CWJJSEDEFAULT, NULL, LoadMenu(hlnst, MAKEINTRESOURCE(IDR MAIN)), hlnst): frame ShowWindow(nShow); frame UpdateWindowO: frame MessageLoop(): returnează : } Un exemplu al ferestrei programului nostru este prezentat în Fig ! - Numele programului [Creează și document nou! Orez Un exemplu de program care utilizează clase generice de ferestre cadru Capitolul Abstracția dispozitivului grafic Dacă credeți că structura TBBUTON este folosită incorect aici, probabil că ați citit documentația greșită Structura Win TBBUTTON constă din șapte câmpuri MSDN și alte documentații nu menționează al cincilea câmp: BYTE bReserved[ ] Compilatorul C++ îngăduie inexactitățile până când începeți să lucrați cu ultimele două câmpuri în care programul stochează identificatori pentru resursele șirurilor de indicii Exemplu de program: Trasarea în contextul dispozitivului Ieșirea grafică în mediul Windows, la fel ca majoritatea altor procese, este determinată de evenimente Este de așteptat ca o aplicație să fie întotdeauna capabilă să își redea imaginea completă, deoarece ecranul este partajat de mai multe ferestre care aparțin diferitelor aplicații Când o fereastră trebuie redesenată, un mesaj WM PAINT este trimis la funcția de fereastră Joacă un rol cheie în ieșirea grafică realizată în programele Windows, dar nu este ușor de descris conceptual Mesajul WM PAINT este generat automat de managerul de ferestre atunci când fereastra este vizibilă, când nu mai există mesaje urgente în sistem și o regiune de actualizare negoală este asociată ferestrei Regiunea ferestrei actualizată Regiunea de actualizare a unei ferestre este determinată de mai mulți factori—caseta de delimitare a ferestrei; regiunea specificată de funcția SetWindowRgn și relația acesteia cu alte ferestre de pe desktop Mesajul WM PAINT nu este pus în coada de mesaje a firului de execuție și nu este tratat ca și alte mesaje În schimb, atunci când o fereastră trebuie redesenată, este setat un bit care determină planificatorul ferestrei să apeleze direct handlerul de mesaje al ferestrei atunci când nu există alte mesaje în coadă O altă modalitate de a forța o redesenare a ferestrei este apelarea funcției UpdateWindow Inițial, regiunea ferestrei de actualizat este goală Starea sa este actualizată atunci când sunt apelate următoarele funcții: BOOL InvalidateRectCHWND hWnd CONST RECT * IpRect BOOL beErase): BOOL Val dateRect(HWND hWnd CONST RECT * IpRect); BOOL InvalidateRgn(HWND hWnd HRGN hRgn, BOOL bErase); BOOL ValidateRgn(HWND hWnd HRGN hRgn); Funcțiile InvalidateRect/InvalidateRgn includ un dreptunghi sau o regiune în regiunea ferestrei care este actualizată Dacă în apel este trecut NULL, întreaga zonă client a ferestrei este inclusă în regiunea care se actualizează Funcțiile Validate-Rect/ValidateRgn fac opusul: exclud un dreptunghi sau o regiune din regiunea ferestrei care este actualizată Dacă se trece NULL în apel, întreaga zonă client a ferestrei este exclusă din regiunea în curs de actualizare Parametru Exemplu de program: Trasarea în contextul dispozitivului bErase spune managerului de ferestre dacă să genereze un mesaj de ștergere de fundal WM ERASEBKGND atunci când este apelat BeginPaint Regiunea de actualizare a unei ferestre se schimbă și atunci când fereastra este redimensionată sau derulată sau când o altă fereastră deasupra acesteia este ștearsă, mutată sau redimensionată Când fereastra este redimensionată, este generat un mesaj WM SIZE; Managerul de ferestre verifică steagurile CS HREDRAW și CSJ/REDRAW în stilul clasei de ferestre (WNDCLASSEX style), nu în stilul ferestrei în sine Dacă este setat indicatorul CS HREDRAW sau CS VREDRAW, atunci modificarea lățimii sau înălțimii ferestrei invalidează întreaga zonă client; în caz contrar, numai zona de fereastră adăugată este invalidată Orice redimensionare a ferestrei are ca rezultat redesenarea imediată a acesteia Când utilizatorul redimensionează fereastra trăgând cadrul, managerul de ferestre simulează de obicei doar redimensionarea ferestrei până când butonul mouse-ului este eliberat Sistemele de operare mai noi din familia Windows (Windows , și ) au o casetă de selectare în aplicația Afișaj din Panoul de control care controlează acest mod Dacă caseta de selectare Afișare conținutul ferestrei în timpul tragerii este bifată în fila Efecte, mesajul de redimensionare este generat în mod repetat în timpul procesului de glisare Dacă redesenarea ferestrei este lentă, poate provoca întârzieri serioase Derularea unei ferestre sau a contextului de dispozitiv asociat acesteia face ca fereastra să fie redesenată Când derulați o fereastră sau zona clientului acesteia, pixelii se deplasează în sus sau în jos, la stânga sau la dreapta, iar în fereastră apar zone noi de conținut nedesenate Astfel de zone sunt incluse și în regiunea actualizată a ferestrei Informațiile despre regiunea curentă a ferestrei care este actualizată sunt returnate de două funcții: int GetUpdateRgn(HWND hWnd, HRGN hRgn, BOOL bErase); BOOL GetUpdateRect(HWND hWnd, LPRECT IpRect, BOOL bErase); Funcția GetUpdateRgn returnează regiunea ferestrei care urmează să fie actualizată prin handle-ul existent al regiunii hRgn; cu alte cuvinte, înainte de apelul funcției, mânerul hRgn trebuie să conțină mânerul real al obiectului regiune, iar după apelul funcției, acesta conține datele regiunii ferestrei care se actualizează Funcția GetUpdateRect returnează pur și simplu dreptunghiul de delimitare pentru regiunea ferestrei care este actualizată Parametrul bErase controlează dacă mesajul WM ERASEBKGND este trimis dacă regiunea care este actualizată nu este goală mesaj WM PAINT Când un mesaj WM PAINT ajunge într-o funcție de fereastră, aplicația apelează de obicei funcția BeginPaint Funcția BeginPaint primește contextul dispozitivului și inițializează regiunea sistemului cu intersecția regiunii vizibile a ferestrei cu regiunea în curs de actualizare Înainte de a reveni de la BeginPaint, regiunea în curs de actualizare este declarată validă (adică resetată), astfel încât sistemul să poată începe un nou ciclu de acumulare a regiunii care se actualizează Capitolul Abstracția dispozitivului grafic Pe lângă returnarea HDC-ului, funcția BeginPaint completează și structura PAINTSTRUCT: typedef struct { hdc hdc: BOOL beErase: RECT rcPaint: BOOL fRestore: BOOL flncUpdate: BYTE rgbReserved[ ]: }PAINTSTRUCT: Câmpul hdc conține același handle HDC returnat de funcția BeginPaint; valoarea este utilizată de funcția EndPaint pentru a elibera contextul dispozitivului Dacă indicatorul bErase este TRUE, aplicația trebuie să ștergă ea însăși fundalul ferestrei, deoarece toate încercările de a șterge fundalul au eșuat Dacă steag-ul bErase (un steag pentru a șterge fundalul) a fost setat când a fost apelat InvalidateRect sau InvalidateRgn, implementarea BeginPaint trimite un mesaj WM ERASEBKGND la funcția fereastră, care trebuie fie să proceseze mesajul, fie să-l transmită funcției DefWindowProc Acesta din urmă folosește mânerul pensulei de fundal specificat în câmpul WNDCLASSEX pentru a șterge fundalul hbrBackground Dar dacă pensula nu este setată, se consideră că nu a fost posibilă ștergerea fundalului și această sarcină ar trebui rezolvată chiar de aplicația Câmpul rcPaint conține caseta de delimitare a regiunii de sistem curente a contextului (adică regiunea care trebuie revopsită) Există mai multe opțiuni pentru gestionarea mesajului WM PAINT după apelarea BeginPaint Dacă scrieți orice fel de program non-trivial, gândiți-vă la cum să optimizați manipularea WM PAINT R În forma sa cea mai simplă, o funcție de fereastră afișează tot ceea ce dorește în fereastră și lasă toate decupajul la GDI Dacă redesenarea implică calcule complexe și un număr mare de apeluri grafice, pot apărea probleme serioase de performanță A O implementare normală ar trebui să verifice dreptunghiul rcPaint în sine și să redeseneze doar acele obiecte care se intersectează cu acesta Când redesenați porțiuni mici din imagine, acest lucru va duce la o creștere semnificativă a performanței - mai ales într-o situație în care tragerea cadrului ferestrei deschide noi zone A O implementare mai sofisticată poate funcționa direct cu regiunea sistemului Câmpul rcPaint conține dreptunghiul de delimitare al regiunii de sistem, iar acesta din urmă nu trebuie să fie dreptunghiular deloc Regiunea sistemului poate fi mult mai mică decât aria acoperită de dreptunghiul rcPaint Desenarea directă la nivelul regiunii sistemului îmbunătățește viteza de ieșire grafică R Dacă rezultatul durează mult, merită să luați în considerare o tehnică de reîmprospătare treptată a ferestrei De exemplu, încărcarea unei imagini bitmap mare poate dura foarte mult timp într-un browser web Managerul de mesaje WM PAINT ar trebui să afișeze rapid informațiile disponibile pe Exemplu de program: Trasarea în contextul dispozitivului computerul local și revine controlul și apoi actualizați fereastra când sosesc date noi Între timp, utilizatorul poate derula prin fereastră, poate vedea informațiile afișate și chiar poate încheia vizualizarea Regiunea sistemului de context dispozitiv a fost ascunsă de programatori de mult timp Noile versiuni ale fișierelor antet Windows documentează funcția GetRandomRgn, care vă permite să obțineți informații despre regiunea sistemului Deși această funcție a fost de mult exportată din GDI DLL, înainte era considerată nedocumentată Int GetRandomRgn(HDC hDC HRGN hrgn, INT INiim); Singura valoare documentată pentru parametrul INum este SYSRGN, dar alți indecși nedocumentați pot fi trecuți în apel pentru a obține alte regiuni asociate cu DC (acest subiect este tratat în Capitolul ) Funcția GetRandomRgn(hDC, hRgn, SYSRGN) copiază datele de regiune de sistem ale contextului dispozitivului în datele de regiune specificate de mânerul hRgn; înainte de a apela funcția, acest manipulator trebuie să corespundă unui obiect regiune valid Regiunea rezultată este descompusă în dreptunghiuri de către funcția GetRegionData Dacă toate acestea sună prea confuz, nu vă grăbiți - întregul proces este tratat în detaliu în Capitolul Înainte de a reveni de la handlerul WM PAINT, funcția fereastră trebuie să apeleze funcția EndPaint, care eliberează opțional resursele asociate contextului dispozitivului sau returnează contextul partajat în cache Reprezentare vizuală a mesajelor de redesenare a ferestrei În implementarea normală a WM PAINT, regiunea actualizată este redesenată astfel încât noua imagine să se potrivească perfect cu imaginea prezentă pe ecran Dar, ca programatori, dorim să obținem o reprezentare vizuală a mesajelor WM PAINT - pentru a vedea când sunt generate, cât de mult din imagine este inclusă în regiunea sistemului și pentru a afla dacă manipulatorul de context al dispozitivului este folosit în mod repetat sau recreat de fiecare dată În plus, am dori să observăm generarea și procesarea altor mesaje legate de redesenare (cum ar fi WM NCCALCSIZE, WM NCPAINT, WM ERASEBKGND și WM SIZE) Lista prezintă programul WinPaint pentru a vă ajuta să înțelegeți mai bine modul de utilizare a mesajului WM PAINT Programul este construit pe deasupra setului de clase de ferestre generice construit în secțiunea „Exemplu: Clasa de ferestre cadru generic” Lista Program WinPaint: Vizualizarea mesajelor WM PAINT // WinPaint cpp #define STRICT #define WIN LEAN AND MEAN # nclude #include Continuare Capitolul Abstracția dispozitivului grafic Lista Continuare #include #include „ a ainclude\win h” # nclude „ a ainclude\canvas h” #include „ A Ainclude\Status h” # nclude „ A Ainclude\FrameWnd h” #include „ A Ainclude\LogWindow h” # include „resource h” clasa KMyCanvas : KCanvas public { virtual void OnDraw(HDC hDC const RECT * rcPaint): virtual LRESULT WndProc(HWND hWnd UINT uMsg WPARAM wParam LPARAMIParam); int int HRGN KLogWindow DWORD m nRepaint: m Red m Verde m Albastru: m hRegiune; m Log: m Redesenați: public: BOOL OnCommand(WPARAM wParam LPARAM IParam): KMyCanvas mjiRepaint= : m hRegion = CreateRectRgn(O, ) m Roșu m Verde m Albastru m Redesenează = x F; = x F:=OxCF: = ; BOOL KMyCanvas: - OnCommand(WPARAM wParam LPARAM IParam) { comutator ( LOWORD(wParam) ) { caz IDM VIEW HREDRAW: cazul IDM VIEW VREDRAW: { HMENU hMenu = GetMenu(GetParent(m hWnd)): MENUITEMINFO mii: memset(&mii sizeof(mii)): mii cbSize » sizeof(mii): mii fMask » MIIM STATE: if ( GetMenuState(hMenu, LOWORD(wParam) Exemplu de program: Trasarea în contextul dispozitivului MF BYCOMMAND) și MF CHECKED ) mii fState = MFJJNCHECKED: el se mii fState = MF CHECKED: SetMenuItemInfo(hMenu, LOWORD(wParam), FALSE și mii); if ( LOWORD(wParam)==IDM VIEW HREDRAW ) m Redraw x= WVR HREDRAW: el se m Redesenează x= WVRJ/REDRAW; } returnează TRUE: cazul IDM FILE EXIT: DestroyWindow(GetParent(m hWnd)): returnează TRUE: } return FALSE: // Mesajul nu a fost procesat } LRESULT KMyCanvas::WndProc(HWND hWnd UINT uMsg WPARAM wParam, LPARAM Param) { LRESULT Ir: comutator (uMsg) { caz WM CREATE: rnJiWnd = hWnd: m Log Create(m hInst, „WinPaint”): m log Log("WM CREATE\r\n"); returnează : cazul WM NCCALCSIZE: m Log Log("WM NCCALCSIZE\r\n"); Ir = DefWindowProc(hWnd, uMsg, wParam, Param); m Log Log ("WM NCCALCSIZE returnează £x\r\n", Ir): if(wParam) { Ir &= ~ (WVRJHREDRAW | WVRJ/REDRAW); Ir |= m Redesenați: } pauză: cazul WM-NCPAINT: m Log Log("WM NCPAINT HRGN W\r\n", (HRGN) wParam): Ir = DefWindowProc(hWnd, uMsg, wParam Param): m Log Log ("WN NCPAINT returnează\r\n"): pauză: caz WM-ERASEBKGND: m Log Log("WM ERASEBKGND HDC W\r\r", (HDC) wParam): Ir = DefWindowProc(hWnd, uMsg wParam, IParam): Continuare^ Capitolul Abstracția dispozitivului grafic Lista Continuare m Log Log("WM ERASEBKGND returnează\r\n"): break; caz WM SIZE; m Log Log("WM SIZE tip fcd width fcd, helght fcd\r\n" wParam, LOWORD( Param), HIWORD( Param)); Ir = DefWindowProc(hWnd, uMsg, wParam, IParam); m Log Log("WM SIZE returnează\r\n"); pauză; caz WM-PAINT: { PAINTSTRUCT ps: m Log Log("WM PAINT\r\n"); m Log Log("BeginPaint\r\n"); HDC hDC = Beg nPaint(m hWnd, &ps); m Log Log("BeginPa nt returnează HDC $ x\r\n", hDC); OnDraw(hDC, &ps rcPaint); m Log Log("EndPaynt\r\n"); EndPaint(m hWnd, &ps); m Log Log("EndPaint returnează " "Get bjectType(W x)=$d\r\n", hDC, GetObjectType(hDO); m Log Log("WM PAINT returnează\r\n"); } întoarce ; Mod implicit: Ir - DefWindowProc(hWnd, uMsg, wParam, IParam); } întoarcere Ir; } void KMyCanvas::OnDraw(HDC hDC const RECT * rcPaint) { RECT rect; GetClentRect(m hWnd, & rect); GetRandomRgn(hDC, m hRegion, SYSRGN); POINTOrigine; GetDCOrgEx(hDC, &Origin); if ( ((nesemnat) hDC) & xFFFFOOOO ) OffsetRgn(m hRegion, -Origin x, -Origin y): mjnRepaint++; mesaj TCHAR[ J; wsprintf(mess, T ("HDC OxfcX, Org(fcd, fcd)") hDC, Origin x, Origin y); Exemplu de program: Trasarea în contextul dispozitivului if ( m pStatus ) m pStatus->SetText(pane l, mess); comutator ( mjiRepaint % ) { cazul : m Red = (m Red + x ) & OxFF; pauză; cazul : m Verde= (m Verde + x ) & OxFF; pauză; cazul : m Blue = (m Blue + x ) & OxFF; pauză; SetTextAlign(hDC, TA TOP | TA CENTER); int size = GetRegionData(m hRegion , NULL); intreccount = ; daca (dimensiune) { RGNDATA * pRegion = (RGNDATA *) new charEsize]; GetRegionData(m hRegion, dimensiune, pRegion); const RECT * pRect = (const RECT *) & pRegion->Buffer; rectcount = pRegion->rdh nCount; TEXTMETRIC tm; GetTextMetrics(hDC, &tm); int ineheight = tm tmHeight + tm tmExternalLeading; pentru (nesemnat ie ; i rdh nCount; i++) { int x = (pRectEi] stânga + pRectEi] dreapta)/ ; int y = (pRectEi] sus + pRectEi] jos)/ ; wsprintf(mess, "WM PAINT $d rect fcd", m nRepaint, i+ ); ;;TextOut(hDC, x, y - înălțimea liniei, mizerie, tcslen(mizerie)): wsprintf(mess, "(fcd, fcd fcd, W pRectEi] stânga, pRectEi] sus, pRectEi] dreapta, pRectEi] jos); :;TextOut(hDC, x, y, mizerie, tcslen(mizerie)); } șterge [] (char *) pRegion; } wsprintf(mess, T("WM PAINT mesaj fcd $d rects in sysrgn"), mjiRepaint rectcount); if ( m pStatus ) m pStatus->SetText(pane mizerie); HBRUSH hBrush = CreateSolidBrush(RGB(m Red m Green, m Blue)); FrameRgn(hDC, m hRegion, hBrush , ); FrameRgn(hDC, m hRegion, (HBRUSH) GetStockObject(WHITE BRUSH), , ); Continuare^ Capitolul Abstracția dispozitivului grafic Lista Continuare DeleteObject(hBrush); } int WINAPI WinMain(HINSTANCE hlnst, HINSTANCE, LPSTR, int nShow) { Pânză KMyCanvas; Stare KStatusWindow; Cadrul KFrame(hlnst, NULL, , NULL și pânză și stare); frame CreateEx(O, JF( „CIassName”), T(„WinPaint”), WS OVERLAPPEDWINDOW CWJJSEDEFAULT CWJJSEDEFAULT, CWJJSEDEFAULT CWJJSEDEFAULT, NULL LoadMenu(hInst MAKEINTRESOURCE(IDR MAIN)) hlnst): frame ShowWindow(nShow); cadru UpdateWindowO; cadru MessageLoopO; întoarce ; } Probabil că așteptați explicații detaliate O listă lungă de fișiere include este un semn sigur că folosim clase prefabricate Programul folosește clasele KWindow, KCanvas, KToolbar, KFrame și noua clasă KLogWindow Clasa KLogWindow gestionează o fereastră temporară „EDIT” cu mai multe linii care stochează informațiile înregistrate Acestea și alte clase sunt legate într-o bibliotecă care este inclusă în program Clasa KMyCanvas este derivată din KCanvas Acesta redefinește funcția ferestrei, precum și handlere pentru mesajele de comandă și mesajele redesenate Noua funcție OnCommand gestionează două comenzi de meniu care comută starea steagurilor de redesenare la redimensionarea verticală și orizontală Au fost deja menționate mai sus steaguri CS HREDRAW și CS VREDRAW ale structurii WNDCLASSEX, care determină dacă zona client ar trebui redesenată atunci când fereastra este redimensionată Funcția KMyCanvas::OnCommand vă permite să comutați indicatorul intern m Redraw, care este luat în considerare la procesarea WM NCCALCSIZE Noua funcție de fereastră gestionează un număr de mesaje legate de desenul ferestrei - WM NCCALCSIZE, WM NCPAINT, WM NCPAINT, WM ERASEBKGND, WM SIZE și, în final, WM PAINT În acest caz, procesarea se reduce la apelarea funcției standard de fereastră DefWindowProc (excepția este mesajul WM PAINT procesat prin metoda OnDraw) Totuși, programul nu se limitează la un simplu transfer de control, ci înregistrează și date înainte și după procesarea mesajelor La procesarea WM PAINT, datele salvate sunt transmise înainte și după apelurile către BeginPaint și EndPaint La procesarea mesajului WM NCCALCSIZE, fereastra are posibilitatea de a calcula dimensiunea zonei client Manipularea sa are un aspect util - când wParam este TRUE, funcția ferestrei ar trebui să returneze WVR HREDRAW și/sau WVRJ/REDRAW dacă redimensionarea ferestrei face ca întreaga zonă client să fie redesenată Astfel, acest mesaj este de fapt Exemplu de program: Trasarea în contextul dispozitivului Apelează steaguri CSVREDRAW și CSHREDRAW cu managerul de ferestre Programul modifică rezultatul primit de la DefWindowProc, ținând cont de modul selectat de utilizator în meniul programului Astfel, efectele setării acestor steaguri pot fi observate fără recompilarea programului de testare Funcția KMyCanvas: : nDraw este scrisă în așa fel încât mesajul WM PAINT să fie reprezentat vizual în fereastra programului Funcția începe prin obținerea de informații despre dimensiunea zonei client, regiunea sistemului și punctul de bază al contextului dispozitivului Există două interpretări diferite ale regiunii sistemului Pe Windows NT/ , regiunea sistemului este specificată în sistemul de coordonate de pe ecran (sau fizic); în Windows / , regiunea sistemului este specificată în sistemul de coordonate client Programul verifică dacă funcționează sub Windows NT/ , iar dacă verificarea dă un rezultat pozitiv, trece la coordonatele clientului folosind funcția OffsetRgn Deoarece știm că stick-urile GDI pe de biți sunt folosite doar pe Windows NT/ , programul determină versiunea sistemului de operare prin simpla verificare a cuvântului înalt al stick-ului HDC Programul afișează apoi mânerul și punctul de bază de context în primul panou al barei de stare și calculează culoarea pentru a afișa regiunea sistemului La procesarea fiecărui mesaj WM PAINT, programul schimbă una dintre componentele de culoare (roșu, verde sau albastru) După aceea, totul este gata pentru a analiza regiunea, care poate fi goală, consta dintr-un dreptunghi sau sute de dreptunghiuri Programul apelează de două ori funcția GetRegionData Prima dată, funcția este apelată pentru a obține dimensiunea datelor regiunii, iar a doua oară este apelată pentru a obține datele în sine Și din nou, nu ar trebui să vă aprofundați în sensul a ceea ce se întâmplă mult timp; detaliile vor fi date în Capitolul Pentru fiecare dreptunghi, programul imprimă numărul și coordonatele centrului După procesarea tuturor dreptunghiurilor, programul afișează numărul mesajului WM PAINT și numărul de dreptunghiuri în al doilea panou al barei de stare În cele din urmă, conturul regiunii sistemului este conturat cu un chenar alb de un pixel gros și un chenar colorat de trei pixeli Acum rulați programul și experimentați cu el Veți înțelege cum sunt generate mesajele WM PAINT și ce zonă ocupă acestea Pe fig Figura arată cum arată programul când fereastra este redimensionată pe rând de-a lungul ambelor axe Primul mesaj WM PAINT redesenează fereastra la dimensiuni standard Apoi reducem dimensiunea ferestrei; aceasta generează un al doilea mesaj WM PAINT a cărui regiune de sistem nu conține dreptunghiuri Fereastra este apoi minimizată și restaurată, ceea ce generează un al treilea mesaj pentru a redesena zona client redusă (primul dreptunghi din Figura ) Redimensionarea unei ferestre într-o direcție generează mesaje WM PAINT cu o regiune de sistem constând dintr-un singur dreptunghi Dar când fereastra este scalată în ambele direcții în același timp, un mesaj WM PAINT este generat cu o regiune de sistem de două dreptunghiuri (dreptunghiuri și pentru mesajul WM PAINT numărul ) Dacă deschideți și închideți meniul, nu este generat niciun mesaj WM PAINT deoarece sistemul salvează imaginea când meniul este afișat și o restabilește automat Dar dacă Capitolul Abstracția dispozitivului grafic acoperiți fereastra programului cu o altă fereastră sau trageți fereastra de pe marginea ecranului și readuceți-o la locul său, vor apărea cu siguranță mesajele redesenate Dacă setați steaguri CS HREDRAW și CS VREDRAW în meniul View, atunci când fereastra este redimensionată, întreaga zonă client este redesenată, nu doar porțiunile nou apărute Dacă caseta de selectare Afișare conținut fereastră în timpul tragerii este bifată în aplicația Afișare a panoului de control, mesajele de redesenare frecvente sunt generate atunci când fereastra este trasă din cadru ^BeginPaint WM NCPAINT HRGN f i*WN NCPAINT return;; WM ERASEBKGND HDC WM ERASEBKGND reti BeginPaint return;? EndPaint EndPaint returnează (i |WM PAINT returnează ; i?WM NCCALCSIZE aWM NCCALCSIZE reții ilWM SIZE tip , wi WM-SIZE returnează i|WM PAINT L br* - ' "', ' kcPAINT , rect > M PAINT , rect ( , , , ) ( , , , ), sі hsi PAINT , rei , , , WM PAINT , rect ( , , , ) VOPSEA , i , , , WM PAINT , rect ( , , , ) Orez Secvența de trimitere a mesajelor WM PAINT când fereastra este redimensionată Fereastra din stânga afișează și rezultate destul de interesante Mai jos este un protocol pentru redimensionarea unei singure ferestre, căptușit pentru claritate WM-NCCALCSIZE WM NCCALCSIZE returnează O WM SIZE tip lățime , helght WM SIZE revine WM PAINT BeginPaint WM NCPAINTHRGN e WM NCPAINT revine WM ERASEBKGND HDC ERASEBKGND WM ERASEBKGND revine BeginPaint returnează HDC EndPaint EndPaint returnează GetObjectType( b ae)= WM PAINT revine Când utilizatorul termină de glisat chenarul ferestrei într-o nouă poziție, este generat un mesaj WM NCCALCSIZE, urmat de mesajele WM SIZE și WM PAINT În timpul procesării WM PAINT, funcția BeginPaint generează un mesaj WM NCPAINT pentru a redesena zonele non-client și un mesaj WM ERASEBKGND pentru a șterge fundalul Când este apelat WM ERASEBKGND, este transmis handle-ul de context al dispozitivului returnat de funcția BeginPaint Este interesant de observat că în Rezultate Pe Windows NT/ , după ce EndPaint iese, indicatorul de context al dispozitivului returnat de BeginPaint devine invalid (GetObjectType returnează ), dar după câteva apeluri repetate, acest indicator HDC reapare Acest lucru demonstrează că motorul grafic menține un cache global de mânere de context de dispozitiv Rezultate Acest capitol se concentrează pe unul dintre cele mai importante concepte în programarea grafică în mediul Windows - contextele dispozitivului Am considerat o clasă importantă de dispozitive grafice - adaptoare video; a învățat cum să enumerați dispozitivele de afișare cu moduri video acceptate și cum să obțineți informații despre capabilitățile dispozitivului În plus, acest capitol descrie diferitele tipuri de contexte de dispozitiv și cum să le creați O atenție deosebită a fost acordată contextelor dispozitivelor asociate cu anumite ferestre De asemenea, a fost considerat controlul ieșirii grafice în fereastră folosind regiunea de fereastră actualizată La sfârșitul capitolului, au fost create clase C++ care demonstrează conceptele de programare grafică Windows folosind ca exemplu procesarea vizuală a mesajelor WM PAINT Cu toate acestea, întregul material din acest capitol este doar o descriere generală a contextelor dispozitivului și a relației lor cu windowing Utilizarea contextelor dispozitivului pentru trasare va fi tratată în detaliu în capitolele următoare Exemple de programe Spre deosebire de capitolele și , exemplele din acest capitol sunt programe Windows destul de normale Ele demonstrează unele caracteristici subtile ale contextelor dispozitivului și relația lor cu afișarea ferestrei (Tabelul ) Tabelul Capitolul Programe Descriere director de proiect Samples\Chapt \Device Obțineți o listă de dispozitive cu ecran, modul video mov, obținând informații despre capacitățile dispozitivului și atributele contextului Samples\Chapt \Elipse Demonstrarea posibilității de a crea un dreptunghiular nyh și ferestre nedreptunghiulare Samples\Chapt \FrameWindow Exemplu de program pentru testarea familiei clase de ferestre de cadru Samples\Chapt \WinPaint Reprezentarea vizuală a mesajelor redesenate fereastră, regiune de sistem și steaguri CS HREDRAW și CS VREDRAW Capitolul Sisteme de coordonate și transformări Informațiile despre toate obiectele pe care le reprezintă o aplicație sunt stocate în structuri de date De exemplu, un program de computer de aspect stochează descrieri ale paragrafelor de text, imagini, grafică vectorială, anteturi și subsoluri de pagină în structuri, iar o aplicație de proiectare a grădinii funcționează cu obiecte reprezentând plante, garduri, poteci, gazon etc Astfel de structuri de date sunt numite modele În acest capitol, ne interesează o categorie specială de modele - modele geometrice care descriu dimensiunea și locația obiectelor, forma, culoarea, suprafața și alte proprietăți ale acestora Obiectele sunt de obicei dimensionate și poziționate în unități fizice adecvate, cum ar fi inci sau metri La descrierea formei obiectelor, se pot folosi primitive grafice (dreptunghiuri, cercuri, poligoane etc ) Diferite aplicații modelează lumea din jurul lor în diferite sisteme de coordonate De exemplu, în programele de proiectare pe computer, atunci când se modelează un aspect, un punct ( / inch) este de obicei selectat ca unitate de bază, iar într-un sistem de proiectare asistată de computer, unitatea de bază poate fi egală cu , mm Când un utilizator încearcă să creeze un aspect de pagină, un model de broderie sau un plan de grădină, aplicația trebuie să ofere utilizatorului mijloacele de a mări și de a muta obiectele afișate Ar fi extrem de ineficient din punctul de vedere al aplicației să se recalculeze toate datele de locație și dimensiune stocate înainte de sosirea cererii Destul de des, obiectele au o anumită asemănare, ceea ce ne permite să ne limităm la o descriere detaliată doar a uneia dintre ele și să construim restul instanțelor folosind operațiile de reflectare a oglinzii, rotație, distorsiune sau combinațiile lor De exemplu, o imagine a unei grădini de trandafiri poate fi construită repetând de mai multe ori imaginea unui trandafir Sistemul de coordonate fizice Din motive practice, Win GDI a implementat suport pentru mai multe niveluri de sisteme de coordonate, configurabile printr-o matrice de transformare și alte atribute de context dispozitiv În mod tradițional, GDI folosește un sistem de coordonate carteziene bidimensional cu două axe care vă permit să specificați poziția oricărui punct din plan Implementarea Win API în Windows NT/ acceptă patru niveluri de coordonate О Sistemul de coordonate mondial - oferă transformări afine la coordonatele paginii Sistemul de coordonate mondial este format din de unități pe orizontală și de unități pe verticală, deoarece Win reprezintă coordonatele ca numere de de biți A Page Coordinate System - Oferă transformări limitate sistemului de coordonate al dispozitivului Sistemul de coordonate a paginii este format din de unități orizontale și de unități verticale О Sistemul de coordonate al dispozitivului - descrie pixelii individuali ai contextului dispozitivului; acceptă maparea la zone dreptunghiulare ale sistemului de coordonate fizice Sistemul de coordonate al dispozitivului este de de unități orizontale și de unități verticale, deoarece reprezentarea internă a motorului grafic Windows NT/ folosește numere cu virgulă fixă semnate cu biți pentru partea fracțională Un sistem de coordonate fizice - constă din pixeli pe suprafața grafică a unui dispozitiv fizic Sistemul fizic de coordonate este format din de unități orizontale și de unități verticale NOTĂ - Windows / utilizează o implementare complet diferită a sistemelor de coordonate și a transformărilor Funcționarea Windows / GDI se bazează în mare măsură pe implementarea pe biți a GDI moștenit de la Windows , care nu a acceptat transformările lumii și a trunchiat toate coordonatele la valori de biți Mai precis, deși Windows / apelurile la funcțiile grafice GDI pe de biți trec coordonate pe de biți, acestea sunt trunchiate la valori de biți atunci când gdi dll accesează implementarea GDI pe biți Să ne uităm la aceste sisteme de coordonate în ordine inversă - de la coordonatele fizice la cele mondiale Sistemul de coordonate fizice Sistemul de coordonate fizice este utilizat de driverul dispozitivului grafic și este o matrice de pixeli cu o înălțime și o lățime fixe În colțul din stânga sus este un punct cu coordonatele ( , ) Axa x este de la stânga la dreapta, iar axa y este de sus în jos În motorul grafic Windows NT/ , coordonatele sunt reprezentate ca numere semnate cu virgulă fixă, constând dintr-o parte întreagă de de biți și o parte fracțională de biți Puncte cu coordonate negative Capitolul Sisteme de coordonate și transformări mi, precum și cu coordonatele care depășesc lățimea și înălțimea suprafeței dispozitivului, sunt considerate tăiate Astfel, dimensiunea maximă a unui dispozitiv fizic este de x pixeli, sau aproximativ x m² * la de puncte pe inch (dpi) Sistemul fizic de coordonate este ilustrat în fig Coordonatele fizice sunt utilizate în interfața DDI între motorul grafic și driverele dispozitivului grafic Rețineți că este posibil ca coordonatele fizice să nu corespundă cu sistemul de coordonate final care determină locația fiecărui pixel de ieșire; sunt așa doar din punctul de vedere al sistemului grafic Windows Driverul de dispozitiv poate mări primitivele grafice cu transformări suplimentare de coordonate Să presupunem că driverul PostScript convertește coordonatele fizice primite în valori reale date în puncte ( / de inch) Datele PostScript generate pot fi tipărite pe diferite imprimante cu rezoluții diferite Destul de ciudat, nu există o modalitate ușoară în Windows de a determina dimensiunea unui dispozitiv fizic dintr-un handle de context Apelurile către GetDevice-Caps(hDC, HORZRES) și GetDeviceCaps(hDC, VERTRES) funcționează de obicei bine, dar pentru contextele conforme și metafișier, ele returnează dimensiunile contextului dispozitivului de referință Pentru un context de dispozitiv compatibil, dimensiunile suprafeței fizice sunt determinate de dimensiunile rasterului selectat în acesta Puteți utiliza funcția GetObjectType și puteți determina că aveți de-a face cu un obiect OBJ MEMDC, apoi apelați GetObject pentru a obține o copie a structurii BITMAP sau DIBSECTION a rasterului selectat într-un context compatibil; structura stochează dimensiunile rasterului selectat Contextul dispozitivului metafișier nu este deloc specific dispozitivului în timpul construcției, iar dimensiunea acestuia poate crește și micșora pe măsură ce grafica este scrisă Sistemul de coordonate al dispozitivului primitivi Antetul metafișier extins (structura ENHMETAFILEHEADER) conține informații despre dimensiunea imaginii atât în coordonate logice, cât și fizice Cu toate acestea, nu toți pixelii de pe o suprafață fizică pot fi afișați de un dispozitiv Dispozitivele de copiere pe hârtie (imprimante etc ) au restricții mecanice la ieșirea punctelor la marginea paginii Aplicația trebuie să obțină informații despre partea tipărită a paginii folosind funcția GetDeviceCaps Pentru un dispozitiv cu ecran, coordonatele fizice sunt numite și coordonate ecran Coordonatele ecranului sunt utile în operațiunile de ferestre De exemplu, funcția GetWindowRect returnează dreptunghiul de delimitare al ferestrei în coordonatele ecranului; în parametrii mesajelor precum WM NCMOUSEMOVE sunt transmise și coordonatele ecranului Sistemul de coordonate al dispozitivului Coordonatele dispozitivului sunt utilizate atunci când lucrați cu contexte de dispozitiv în API-ul Win GDI În termeni generali, sistemul de coordonate al dispozitivului este un subset al sistemului de coordonate fizice corespunzător Pentru contextele de dispozitiv create de funcțiile CreateDC, CreatelC și CreateCompati bleDC, sistemul de coordonate al dispozitivului este identic cu sistemul de coordonate fizic Pentru contextele de dispozitiv asociate cu anumite ferestre (adică cele returnate de apelurile către GetDC, GetWindowDC și BeginPaint), sistemul de coordonate al dispozitivului este determinat de dreptunghiul ferestrei sau de zona sa client Ca și în sistemul de coordonate fizic, colțul din stânga sus al sistemului de coordonate al dispozitivului este ( , ), axa x este de la stânga la dreapta, iar axa y este de sus în jos Cunoscând manipulatorul de context al dispozitivului, puteți afla poziția relativă a sistemului de coordonate al dispozitivului în coordonatele sale fizice folosind funcția GetDCOrgEx Pentru a determina dimensiunea sistemului de coordonate al dispozitivului, trebuie să aflați dacă acesta corespunde zonei client a ferestrei sau întregii ferestre Funcția GetWindowRect sau GetCLientRect este apoi apelată pe mânerul ferestrei returnat de WindowFromDC Figura ilustrează sistemul de coordonate al dispozitivului și relația acestuia cu coordonatele fizice Sistemul de coordonate fizice este reprezentat ca o grilă mare în fundal, iar coordonatele dispozitivului corespund unui dreptunghi mic Colțul din stânga sus al dreptunghiului corespunde punctului ( , ) din sistemul de coordonate fizic Capacitatea aplicației de a afișa în sistemul de coordonate al dispozitivului este limitată de doi factori: regiunea sistemului și meta-regiunea/regiunea de tăiere După cum sa menționat în Capitolul , regiunea de sistem a unei ferestre este intersecția regiunii vizibile a ferestrei cu regiunea de actualizare și este controlată de sistemul de ferestre, în timp ce metaregiunea și regiunea de tăiere sunt controlate de aplicație Trecerea sistemului - Capitolul Sisteme de coordonate și transformări o regiune de context cu o meta-regiune/regiune de tăiere și definește un set de pixeli cu care o aplicație poate lucra printr-un context de dispozitiv Orez Relația dintre sistemul de coordonate al dispozitivului și sistemul de coordonate fizic Punctul de bază, dimensiunile și regiunea de sistem a contextului dispozitivului sunt actualizate automat de către sistem; GDI nu le poate gestiona Prin urmare, maparea sistemului de coordonate logic la cel fizic se realizează printr-o simplă deplasare (transferul punctului de bază) În aplicațiile de grafică interactivă care folosesc mesajele mouse-ului pentru a selecta, muta și edita elemente grafice sau pentru a verifica proprietatea, este nevoie de conversia între coordonatele fizice (de ecran) și coordonatele dispozitivului (în sistemul de coordonate din fereastră sau din zona clientului) API-ul Win oferă mai multe funcții pentru această sarcină BOOL ClientToScreen(HWND hWnd, LPPOINT IpPoint); BOOL ScreenToClent(HWND hWnd, LPPOINT IpPoint): Int MapW ndowPoints(HWND hWndFrom HWND hWndTo,LPPOINT IpPoints, UINT cPoints): Funcția ClientToScreen convertește un punct (PUNCT) din coordonatele zonei client în coordonatele ecranului; funcția ScreenToClient face invers Funcția MapWindowPoints convertește o serie de puncte din sistemul de coordonate al unei ferestre în sistemul de coordonate al altei ferestre Coordonatele dispozitivului sunt utilizate pe scară largă în API-ul Win În zona GDI, regiunile de tăiere sunt specificate exact în coordonatele dispozitivului, și nu în coordonatele paginii sau ale lumii, ceea ce provoacă adesea tot felul de neînțelegeri și probleme Procesul de tăiere este discutat în detaliu în Capitolul Într-o regiune de ferestre, coordonatele dispozitivului sunt de obicei încorporate în coordonate relativ la zona client a ferestrei Ei folosesc Sistemul de coordonate ale paginii și modurile de afișare Acestea sunt folosite pentru a defini parametrii funcțiilor CreateWindow și SetWindowPos, precum și în mesajele legate de locația cursorului mouse-ului, cum ar fi WM MOUSEMOVE și WM LBUTTONDBLCLICK Sistemul de coordonate ale paginii și modurile de afișare Ambele sisteme de coordonate considerate (fizice și dispozitive) sunt limitate la reprezentare sub forma unei matrice de pixeli dependente de dispozitiv Dimensiunea ferestrei pe un ecran de înaltă rezoluție este de obicei diferită de dimensiunea ferestrei pe un ecran cu rezoluție joasă, iar grosimea liniei imprimate de pixeli va depinde de rezoluția imprimantei Pentru ca programarea grafică să fie mai puțin dependentă de dispozitiv, Windows GDI permite aplicațiilor să își creeze propriile sisteme de coordonate logice care aproximează modelele lor geometrice În astfel de sisteme de coordonate este mai convenabil să lucrezi, în plus, acestea sunt mult mai puțin dependente de echipament Unul dintre cele două sisteme de coordonate logice acceptate de Win GDI este sistemul de coordonate a paginii De altfel, acesta este singurul sistem de coordonate logic suportat de sistemele de operare din familia Windows pe biți și chiar de implementările Win în Windows / /CE Al doilea sistem de coordonate logic, coordonatele mondiale, este acceptat numai pe Windows NT/ Din motive istorice, în documentația Windows și chiar în numele funcțiilor, sistemul de coordonate „logic” este de obicei denumit sistem de paginare Sistemul de coordonate a paginii permite unei aplicații să-și construiască geometria în coordonate arbitrare de de biți cu o direcție a axei și o scară fizică arbitrară De exemplu, într-un planificator de grădină, puteți alege o unitate de măsură de bază de / inch (sau un centimetru în sistemul metric), plasați punctul de bază în colțul din stânga jos al lotului, aveți axa x din de la stânga la dreapta și axa y de jos în sus Un astfel de sistem de coordonate este prezentat în Fig De exemplu, dacă gazonul dumneavoastră măsoară de picioare pe picioare și inci, atunci, așa cum se arată în figură, dimensiunile sale sunt date de o pereche de numere ( , ) Când se afișează un model geometric pe un dispozitiv grafic, trebuie să se răspundă la trei întrebări - ce parte a modelului ar trebui să fie afișată, unde ar trebui să fie amplasat pe suprafața dispozitivului și care ar trebui să fie dimensiunile acestuia? Acest lucru vă va permite să afișați diferite fragmente ale modelului la o scară arbitrară și în puncte arbitrare de pe suprafață Când mapați coordonatele paginii la coordonatele dispozitivului, API-ul Win utilizează două concepte care se găsesc adesea în grafica computerizată - fereastră (fereastră) și fereastra (portul de vizualizare) O fereastră este orice zonă dreptunghiulară din sistemul de coordonate a paginii - de exemplu, zona acoperită de gazon din Fig Fenestra de vizualizare este o zonă dreptunghiulară în sistemul de coordonate al dispozitivului Astfel, fereastra determină partea afișată a modelului geometric, iar fereastra determină locația acestuia Capitolul Sisteme de coordonate și transformări mersul pe suprafata aparatului Raportul dintre dimensiuni determină scara ieșirii Orez Proiectarea unei parcele de grădină într-un sistem de coordonate logic Mai precis, o fereastră este definită de patru variabile în coordonatele paginii: WOrgx Punctul de bază al ferestrei, coordonata x WOrgy Punct de bază al ferestrei, coordonata y WExtx Dimensiunile orizontale ale ferestrei WExty Dimensiunile verticale ale ferestrei Fereastra este definită de patru variabile în coordonatele dispozitivului: VOrgx Punctul de bază al ferestrei de vizualizare, coordonată x VOrgy Viewport punct de bază, coordonată y VExtx Viewport dimensiuni orizontale VExty Viewport dimensiuni verticale Punctul (x,r/) din sistemul de coordonate a paginii este mapat la punctul (x',r/') din coordonatele dispozitivului folosind următoarele formule: x' = (x - WOrgx) * VExtx / WExtx + VOrgx y' = (y - WOrgy) * VExty / WExty + VOrgy În aceste formule, pur și simplu calculăm diferența dintre punctul (x,z/) și coordonatele punctului de bază al ferestrei, o scalam în spațiul ferestrei și o adăugăm la coordonatele punctului de bază al ferestrei Transfigurarea Sistemul de coordonate ale paginii și modurile de afișare Apelarea unui punct de la coordonatele dispozitivului la coordonatele paginii se face în același mod: x = (x' - VOrgx) * WExtx / VExtx + WOrgx y = (y' - VOrgy) * WExty / VExtx + WOrgy Sunt posibile următoarele variante de mapări între aceste sisteme de coordonate О Maparea identității Fereastra și fereastra sunt specificate în cvartete ( , , , ); în acest caz x' = x, y' = y, iar coordonatele paginii sunt identice cu coordonatele dispozitivului Despre Offset Fereastra este definită de un cvartet ( , , , ) iar fereastra este (dx, dy, , ); în acest caz x' = x + dx, ay' = y + dy Fiecare punct din spațiul paginii este compensat cu (dx,dy) atunci când este mapat la sistemul de coordonate al dispozitivului Despre scalare Fereastra este definită de un cvartet ( , , , ) iar fereastra este ( , , mx, my); în acest caz x' = x*mx, ay' = y*my Fiecare punct din spațiul paginii, atunci când este mapat la sistemul de coordonate al dispozitivului, este scalat de factori (tx, ty) Scara poate fi un număr arbitrar - întreg sau fracționar, fie mai mare, fie mai mică decât Scalarea de-a lungul axelor xnu se realizează independent O Reflecție Fereastra este definită de un cvartet de ( , , lățime, înălțime) iar fereastra este (lățime, înălțime, -lățime, -înălțime); în acest caz x' = lățime - x, ay' = înălțime - y La maparea de la coordonatele paginii la coordonatele dispozitivului, desenul poate fi oglindit atât pe axa orizontală, cât și pe cea verticală Reflection vă permite să utilizați direcții ale axei în sistemul de coordonate ale paginii care sunt diferite de direcțiile fixe ale sistemului de coordonate al dispozitivului O Operații combinate Orice combinație a operațiunilor de mai sus API-ul Win acceptă următoarele funcții pentru personalizarea sistemului de coordonate a paginii prin specificarea opțiunilor de fereastră și fereastră de vizualizare: BOOL SetWINdowOrgEx(HDC hDC Int X Int Y LPPOINT pPoint); BOOL SetWindowExtEx(HDC hDC Int X, Int Y, LPSIZE pSize); BOOL SetViewportOrgEx(HDC hDC Int X, int Y LPPOINT pPoint): BOOL SetViewportExtEx(HDC hDC Int X Int Y, LPSIZE pSize): Ultimul parametru al acestor patru funcții este un pointer către o structură POINT sau SIZE care trebuie completată cu datele de stare inițială ale contextului Pentru fiecare dintre aceste funcții, există o funcție de pereche care returnează informații despre fereastră și fereastra de vizualizare Consultați documentația Win pentru o descriere a funcțiilor GetWindowOrgEx, GetWindowExtEx, GetViewportOrgEx și GetViewportExtEx Pare destul de confuz la prima vedere, nu-i așa? Pentru a simplifica munca programatorului, API-ul Win acceptă mai multe presetări ale sistemelor de coordonate ale paginii numite moduri de mapare Majoritatea modurilor de afișare stabilesc dimensiuni preselectate ale ferestrelor și ferestre de vizualizare care determină dimensiunea unității de măsură Capitolul Sisteme de coordonate și transformări reniu în sistemul de coordonate a paginii și factorul de scalare la trecerea la sistemul de coordonate al dispozitivului Cu toate acestea, aplicația poate schimba poziția punctului de bază al ferestrei și al ferestrei de vizualizare, ceea ce vă permite să afișați diferite fragmente ale modelului geometric în diferite părți ale ecranului Modul de afișare a contextului dispozitivului este selectat de următoarea funcție: Int SetMapMode(HDC hDC, Int fnMapMode); Modul de afișare MM TEXT Cel mai simplu mod de mapare MMJTEXT este setat apelând SetMapModeChDC, MM-TEXT) Acest mod este selectat implicit în contextele de dispozitiv nou create Modul de afișare MM TEXT utilizează dimensiuni fixe ale ferestrei și ferestrei ( , ), iar punctele de bază implicite ale ferestrei și ferestrei de vizualizare au coordonate ( , ) Astfel, în mod implicit, coordonatele paginii într-un context de dispozitiv sunt aceleași cu coordonatele dispozitivului În modul MM TEXT, o aplicație poate schimba poziția punctelor de bază ale ferestrei și ferestrei de vizualizare, astfel încât formulele generale pentru conversia coordonatelor paginii în coordonatele dispozitivului arată astfel: x* = x - WOrgx + VOrgx y' = y - WOrgy + VOrgy Setarea axelor în modul MMJTEXT este potrivită pentru redarea textului în direcția standard (de la stânga la dreapta, de sus în jos) Probabil, asta explică alegerea numelui modului Aplicațiile grafice simple îl folosesc adesea și atunci când lucrează cu ecranul Dacă doriți să imprimați în modul MM TEXT, va trebui să recalculați coordonatele și să scalați singur imaginea, astfel încât rezultatul să aibă aceleași dimensiuni pe imprimante cu rezoluții diferite Modul MMJTEXT nu vă permite să schimbați scara relativă a axelor, deoarece proporțiile dimensiunilor ferestrei și ferestrei de vizualizare sunt fixate rigid în el Moduri de afișare MM LOENGLISH și MM HIENGLISH Unitățile fizice utilizate în modurile de afișare MM LOENGLISH și MMHIENGLISH se bazează pe inch, unitatea tradițională de măsură engleză În modul MM LOENGLISH, o unitate de coordonate a paginii corespunde la / inch, în timp ce în modul MM HIENGLISH corespunde la / inch În modul MM LOENGLISH, un inch este egal cu de unități, o jumătate de inch este egal cu de unități, un sfert de inch este egal cu de unități și o optime de inch nu poate fi reprezentată fără pierderea preciziei În modul MM HIENGLISH, un inch este de unități, o jumătate de inch este de unități, un sfert de inch este de unități și o optime de inch este de unități Direcția axei y în aceste două moduri coincide cu direcția sa în sistemul de coordonate carteziene tradițional, adică axa y este direcționată de jos în sus (vezi Fig ) În acest sens, modurile MM LOENGLISH și MM HIENGLISH diferă de modul MMJTEXT, sistemul de coordonate al dispozitivului și sistemul de coordonate fizic Sistemul de coordonate ale paginii și modurile de afișare Selectarea modului de mapare MM LOENGLISH sau MM HIENGLISH într-o aplicație este ușoară - trebuie doar să apelați funcția SetMapMode(hDC, MM LOENGLISH) sau SetMapMode(hDC, MM HIENGLISH) GDI redimensionează automat fereastra și fereastra Mai jos este un exemplu de implementare a acestor două moduri în funcția SetMapMode: BOOL SetMapMode(HDC hDC Int fnMapMode) { // Setați modul de mapare a contextului fnMapMode int mul: Intdlv; swltch(fnMapMode) { caz MM HIENGLISH: mul= : div= : break: caz MM LOENGLISH: mul= : div= : break: implicit: returnează FALSE: } SetWindowExtExChDC GetDeviceCaps(hDC HORSIZE) * mul / div GetDeviceCaps(hDC, VERTSIZE) * mul / div, NUL): SetV newportExtEx(hDC GetDeviceCaps(hDC, HORZRES) - GetDeviceCaps(hDC VERTRES) NUL): returnează TRUE: } Setarea acestor două moduri în contextul dispozitivului utilizează dimensiunile dispozitivului în unități fizice și pixeli De exemplu, dacă setați constanta HORZRES, funcția GetDeviceCaps returnează lățimea suprafeței dispozitivului fizic în pixeli În modurile MM LOENGLISH și MM HIENGLISH, lățimea ferestrei este aceeași cu lățimea suprafeței dispozitivului, iar înălțimea ferestrei este egală cu înălțimea suprafeței dispozitivului cu semnul opus Astfel, axa x păstrează aceeași direcție ca și în sistemul de coordonate al dispozitivului, iar axa y este direcționată în direcția opusă Lățimea ferestrei este calculată prin înmulțirea suprafeței fizice a dispozitivului cu numărul de unități de / inch și împărțind rezultatul la Rețineți că dimensiunile fizice ale dispozitivului sunt în milimetri (un inch este egal cu aproximativ , mm) ) Pentru o dimensiune a ecranului de x pixeli, GetDeviceCaps returnează dimensiunile fizice de x mm Prin urmare, SetMapMode(hDC, MM HIENGLISH) setează dimensiunile ferestrei ( , ) și dimensiunile ferestrei ( ,- ) S-ar putea să vă întrebați de ce rezoluția logică returnată de apelurile GetDeviceCaps(hDC,LOGPIXELSX) și GetDeviceCaps(hDC,LOGPIXELSY) nu este utilizată în locul acestor valori? Utilizarea unei rezoluții logice ar schimba setarea sistemului de coordonate a paginii De exemplu, pentru același ecran de x pixeli, driverul dispozitivului returnează o rezoluție logică Capitolul Sisteme de coordonate și transformări ( , ) Presupunând că dimensiunile fizice ale suprafeței dispozitivului sunt de x inci, dimensiunile ferestrei în modul MM HIENGLISH ar trebui să fie egale cu ( , ) Termenul „boolean” în acest caz înseamnă că valorile nu sunt absolut exacte Driverul de afișare acceptă, de obicei, diferite dimensiuni de buffer de cadre, iar adaptorul video se poate conecta la monitoare de diferite dimensiuni În general, utilizatorii preferă ca documentul să fie afișat clar pe ecran, iar dimensiunile imaginii să fie potrivite pentru citirea și editarea conținutului documentului Nu contează cu adevărat dacă o pagină de dimensiunea Letter este afișată cu exact , inci lățime La rezoluție normală, driverul de afișare raportează că rezoluția logică este de dpi, în timp ce la rezoluție înaltă este de dpi Dar rezultatul tipărit trebuie să fie cu adevărat precis - de exemplu, rezultatul unui program de contabilitate trebuie să se încadreze exact în marginile formularului finit Pentru dispozitivele de hârtie, valoarea rezoluției logice este semnificativă Pe Windows NT/ , interfața GDI se bazează în mare măsură pe dimensiunile dispozitivului grafic furnizate de driverul de afișare pentru a seta modul de afișare Driverul de afișare obține informații despre dimensiunile fizice ale ecranului din driverul portului video Teoretic, driverul de ecran ar putea raporta dimensiunile exacte dacă a primit informații de la monitor Cu toate acestea, autorul nu a văzut încă un singur driver de ecran care să raporteze altceva decât x mm - dimensiunile standard ale unui monitor de inchi Dacă lucrați cu un mod de afișare care depinde de dimensiunile fizice ale dispozitivului, nu utilizați valoarea de rezoluție logică din aplicația dvs pentru a evita potențialele inconsecvențe De asemenea, rețineți că apelarea SetMapMode nu schimbă punctul de bază al ferestrei și ferestrei de vizualizare Valorile originale sunt păstrate, iar aplicația le poate modifica după cum crede de cuviință În ceea ce privește rezoluția, MM HIENGLISH este de dpi și MM LOENGLISH este de dpi MM LOMETRIC moduri de afișare și MM HIMETRIC Modurile de afișare metric MM LOMETRIC și MM HIMETRIC sunt similare cu modurile engleze discutate în secțiunea anterioară În modul MM LOMETRIC unitatea de bază este de , mm, iar în modul MM HIMETRIC este de , mm Ca și în cele două moduri anterioare, axa x este direcționată de la stânga la dreapta, iar axa y este direcționată de jos în sus Pentru a activa suportul pentru modurile de mapare a valorilor, adăugați fragmentul la pseudo-implementarea SetMapMode de mai sus: cazul MM HIMETRIC: mul = ; div= ; pauză: cazul MM LOMETRIC; mul = ; div = : pauză; Rezoluția în modul MM HIMETRIC corespunde la dpi, iar în modul MM LOMETRIC - dpi Sistemul de coordonate ale paginii și modurile de afișare Mod de afișare MM TWIPS Modurile de afișare metrică sunt pentru țările care utilizează sistemul metric Modurile engleze sunt folosite în țările care continuă să funcționeze în unități clasice, dar sunt necesare alte unități pentru imprimare Unitatea tradițională în tipografie este punctul, care este aproximativ / , (sau , ) de inch În sistemele moderne de aranjare a computerelor, punct este normalizat la exact / ( , ) de inch, ceea ce este cu , % mai mare decât dimensiunea originală În aplicațiile Windows, punctele sunt folosite pentru a măsura dimensiunea fontului De exemplu, dimensiunea (dimensiunea) textului tipografic standard este de puncte, iar spația dintre linii este de puncte Punctele sunt unitatea de măsură de bază în PostScript și toate coordonatele și dimensiunile sunt exprimate în puncte flotante Modurile engleză și metrică nu oferă acuratețea necesară la formatarea textului, așa că Win API oferă un mod de afișare suplimentar MM TWIPS pentru astfel de sarcini Unitatea logică în MMTWIPS este / de punct, adică / de inch; aceste unități se numesc twips În afară de anumite unități de măsură, modul de afișare MM TWIPS este similar cu alte moduri bazate pe unități fizice Pentru a activa suportul pentru modul MM TWIPS, următorul fragment ar trebui adăugat la pseudo-implementarea SetMapMode de mai sus: caz MM TWIPS: mul= : div= : break: Inutil să spun că modul MM TWIPS corespunde unei rezoluții de dpi Această rezoluție este de obicei suficientă pentru spațierea precisă atunci când justificați, comprimați și extindeți textul Moduri de afișare MM ISOTROPIC În fizică, termenul „izotrop” înseamnă „având aceleași proprietăți în toate direcțiile” În Win GDI, modul de afișare MM ISOTROPIC corespunde unui mod de afișare arbitrar cu același raport dimensiune fereastră/vizualizare pe ambele axe, indiferent de direcție În termeni formali, arată astfel: abs(WExtx / VExtx) = abs(WExty / VExty) sau abs(WExty / VExty) = abs(WExty / VExty) Pentru a utiliza modul de mapare izotropă, trebuie mai întâi să apelați funcția SetMapMode(hDC,MM ISOTROPIC) Experimentele au arătat că GDI împrumută setările ferestrelor și ferestrelor de vizualizare din modul de afișare MM LOMETRIC După aceea, funcția SetWindowExtEx este apelată mai întâi și apoi funcția SetViewportExtEx; GDI asigură menținerea aceleiași scari pe ambele axe Implementarea modului de afișare izotropă în Windows NT/ nu este perfectă După cum au arătat experimentele noastre, în modul MM ISOTROPIC, funcțiile SetWindowExtEx Capitolul Sisteme de coordonate și transformări și Set ViewportExtEx sunt apelate mai întâi în mod obișnuit, după care GDI efectuează normalizarea în conformitate cu cerințele de izotropie Pentru a face acest lucru, GDI alege dintre WExtx, VExtx, WEtxy și VExty variabila cu cea mai mare valoare absolută și calculează noua sa valoare din cele trei variabile rămase Unele rezultate ale testelor sunt prezentate în tabel Tabelul Setarea modului MM ISOTROPIC Apelul funcției API (abreviat) Dimensiuni ferestre Vizualizați dimensiunile zonei Comentarii SetMapMode(MMJSOTROPIC) ( , ) ( ,- ) Dimensiunile MMLOMETRIC sunt utilizate din anumite motive SetWindowExtEx( , ) ( , ) ( ,- ) Cel mai mare număr este înlocuit cu x / ; eroarea este de , % SetViewportExtEx( , ) ( , ) ( , ) Cel mai mare număr este înlocuit cu x / Acest exemplu apelează funcțiile SetWindowExtEx și Set-VIewportExtEx în secvență Din tabel reiese clar că GDI încearcă să ofere izotropie prin schimbarea numai a numărului cu cea mai mare valoare absolută - o abordare atât de simplistă duce la o eroare mare Valorile rezultate sunt departe de a fi izotrope În acest exemplu, o soluție posibilă a fost să dați dimensiunile ferestrei ( ) și dimensiunile ferestrei ( ); în acest caz, maparea va fi cu adevărat izotropă În GDI, dimensiunile ferestrei și ferestrei de vizualizare sunt reprezentate ca numere întregi Pentru a obține mapări izotrope, uneori este necesar să se efectueze o aproximare, care, așa cum se arată în tabel poate duce la unele încălcări ale izotropiei Autorul vă recomandă să uitați de micile facilități oferite de modul MM ISOTROPIC și să lucrați direct în modul MM ANISOTROPIC Mod de afișare MM ANISOTROPIC Termenul „anizotrop” înseamnă „care are proprietăți diferite în direcții diferite” Cu toate acestea, modul de afișare MM ANISOTROPIC vă permite de fapt să utilizați orice dimensiune de fereastră și fereastră de vizualizare, izotropă sau anizotropă Toate modurile de afișare menționate până acum au dimensiune limitată a ferestrei și personalizare a ferestrei de vizualizare într-o oarecare măsură Modurile MMJTEXT, MM LOENGLISH, MMHIENGLISH, MM LOMETRIC, MM HIMETRIC și MM TWIPS folosesc dimensiuni fixe ale ferestrei și ferestrelor de vizualizare care nu pot fi modificate de aplicație Modul MM ISOTROPIC vă permite să modificați dimensiunile Sistemul de coordonate ale paginii și modurile de afișare tu, dar GDI se asigură automat că scalele de pe ambele axe se potrivesc sau sunt suficient de apropiate MM ANISOTROPIC este singurul mod de afișare în care o aplicație poate redimensiona în mod arbitrar fereastra și fereastra Apelarea SetMapMode(hDC MM ANISOTROPIC) pe un context de dispozitiv setează modul de mapare anizotrop fără a modifica alte atribute Aplicația completează apoi setarea modului de afișare apelând funcțiile SetWindowExtEx și SetViewportExtEx în ordine aleatorie Modul MM ANISOTROPIC vă permite să simulați toate celelalte moduri de afișare, precum și să vă creați propriile moduri Aplicațiile Windows vă permit adesea să alegeți mărirea pentru vizualizarea unui document - %, % etc până la % și % La o scară de %, un pixel de document corespunde unui pixel de ecran, iar un inch din document corespunde unui inch de ecran; la % zoom, se efectuează un zoom : , iar la % zoom, un zoom : De exemplu, într-un editor grafic, unde unitatea logică este un pixel, modul de afișare izotrop pe o scară de m p este stabilit de următorul fragment: SetMapMode(hDC MM ANISOTROPIC); SetExtents(hDC nnmm): Mai jos este funcția SetExtents, care exclude factorii comuni din parametri și setează dimensiunile: int gcddnt X int y) // Cel mai mare multiplu comun { în timp ce (x!=y) dacă (x > y) x -= y: altfel y-= x: returneaza x: } BOOL SetExtents(HDC hDC int wx, int wy, int vx, int vy) { int gx = gcd(abs(wx), abs(vx)); int gy = gcd(abs(wy), abs(vy)): SetWindowExtEx(hDC wx/gx, wy/gy NULL): returnează SetViewportExtEx(hDC, vx/gx vy/gy, NULL): } Dacă un twip ( / dintr-un punct sau / dintr-un inch) este selectat ca unitate logică într-un program de layout de computer, scara twip este setată de următorul fragment: SetMapMode(hDC, MM ANISOTROPIC): SetExtents(hDC, n * , n * , m * GetDeviceCaps(hDC, LOGPIXELSX), m * GetDeviceCaps(hDC LOGPIXELSY)): Acest fragment utilizează rezoluția logică returnată de driverul de dispozitiv Dacă preferați să calculați rezoluția din dimensiunile fizice ale dispozitivului, se procedează astfel: SetMapMode(hDC, MM ANISOTROPIC): SetExtents(hDC, n * , n * , Capitolul Sisteme de coordonate și transformări m * GetDeviceCaps(hDC, HORZRES) * / GetDeviceCaps(hDC, HORZSIZE) / m * GetDeviceCaps(hDC, VERTRES) * / GetDeviceCaps(hDC, VERTSIZE) / ): În acest fragment, dimensiunile sunt date prin numere pozitive, astfel încât direcția axelor din sistemul de coordonate al paginii coincide cu direcția din sistemul de coordonate al dispozitivului Pentru a schimba direcția axelor, este suficient să schimbați semnul dimensiunilor ferestrei de vizualizare Pe lângă cântarele fixe, aplicațiile Windows acceptă adesea calculul de scară online pentru a se potrivi pe o anumită parte a unui document pe toate suprafețele dispozitivului În funcție de dimensiunea suprafeței dispozitivului, lățimea paginii, întreaga pagină sau două pagini adiacente pot fi scalate O funcție generică pentru rezolvarea unor astfel de probleme este prezentată în Lista Lista Plasare în fereastră col x pagini rând BOOL FitPages(HDC hDC int lățimea paginii int înălțimea paginii, int dcwidth int dcheight int col, int rând, int margine int decalaj) { // Calculați dimensiunile totale ale paginilor col x rând int lățime = margine* + lățime pagină *col + gap*(col- ): int inaltime = margine* + inaltime pagina*rand + decalaj*(rand-l); dacă (lățimea dcwidth * dcheight ) { dcheight=dcwidth:height=width: } el se { dcwidth=dcheight:width=inaltime: } returnează SetExtents(hDC width height, dcwidth dcheight); } Această funcție rezolvă problema generală de aranjare a paginilor col x rând, fiecare lățime de pagină x înălțime pagină, într-un spațiu de coordonate dcwidth x dcheight Există margini pe toate cele patru margini ale documentului, iar paginile sunt separate prin intervale dar Programul calculează mai întâi dimensiunile blocurilor finale din paginile col x rând, luând în considerare toți factorii Rapoartele dimensiunii ferestrei/vizualizării sunt apoi comparate de-a lungul celor două axe, iar raportul mai mic este utilizat pentru a ajusta dimensiunea ferestrei Pentru a înțelege mai bine cum funcționează această funcție, vom analiza câteva exemple Să presupunem că dimensiunile fiecărei pagini a documentului sunt de x de unități Sistemul de coordonate ale paginii și modurile de afișare prost, suprafața dispozitivului este de x pixeli, iar marginile și spația dintre pagini sunt Scalarea lățimii paginii poate fi considerată ca o problemă de potrivire a paginii x , adică FitPages(hDC, , , , , , , , ) Un bloc de pagini x este de x unități (cu rotunjire pentru a preveni împărțirea cu ), astfel încât raportul pe axa y ( : ) este mai mare decât raportul pe axa x ( : ) Programul selectează o înălțime a ferestrei de și o înălțime a ferestrei de Dimensiunile finale ale ferestrei sunt ( ) și dimensiunile ferestrei sunt ( , ) Lățimea paginii corespunde lățimii spațiului de coordonate a dispozitivului Să trecem la plasarea a două pagini pe suprafața dispozitivului Un bloc x are dimensiuni de x , astfel încât raportul dintre fereastra și fereastra din axa y ( : ) este mai mic decât raportul din axa x ( : ) Programul alege o lățime a ferestrei de și o înălțime a ferestrei de Acum afișăm ( ) unități cu ( ) pixeli, care este simplificată de funcția SetExtents la ( ) cu ( ) Dimensiunea ferestrei și setările fereastra de vizualizare determină câte unități din sistemul de coordonate ale paginii corespund unui anumit număr de unități din sistemul de coordonate al dispozitivului În Windows GDI, fereastra și fereastra de vizualizare descriu maparea de la sistemul de coordonate al paginii la sistemul de coordonate al dispozitivului, iar tăierea se face independent în coordonatele dispozitivului Aici, doar raporturile dimensiunilor sunt importante, și nu valorile lor specifice De exemplu, în modul MMJTEXT, atât ferestrei, cât și ferestrei de vizualizare li se atribuie dimensiuni ( , ) și puncte de bază ( , ), dar asta nu înseamnă că în sistemul de coordonate este afișat un singur pixel Puncte de bază ale ferestrei și ferestre După setarea dimensiunilor ferestrei și ferestrei, aplicația stabilește poziția punctelor de bază ale ferestrei și ferestrei Când este configurat, GDI mapează punctul de bază al ferestrei în coordonatele paginii cu punctul de bază al ferestrei de vizualizare în coordonatele dispozitivului; punctele rămase sunt afișate în conformitate cu parametrii specificați În mod implicit, punctele de bază ale ferestrei și ferestrei de vizualizare sunt ( , ); alegerea modurilor de afișare și setarea dimensiunilor nu le modifică Pentru a înțelege dacă trebuie schimbate coordonatele punctelor de bază ale ferestrei și ferestrei de vizualizare, programatorul trebuie să cunoască direcțiile axelor chi și y utilizate la ajustarea ferestrei și a ferestrei În modurile MMJTEXT și modul MM ANISOTROPIC (implicit), axa x este de la stânga la dreapta și axa y este de sus în jos Prin urmare, în sistemul de coordonate a paginii, doar primul cadran, definit de valori pozitive de-a lungul axelor x și z, este afișat în spațiul de coordonate al dispozitivului, iar cadranele rămase nu sunt vizibile Dacă doriți ca punctul de bază al sistemului de coordonate al paginii să fie mapat la centrul sistemului de coordonate al dispozitivului, utilizați următorul fragment: SetW ndow rgEx(hDC NULL): SetV ewportOrgEx(hDC dcHelght/ dcW dth/ NULL): Capitolul Sisteme de coordonate și transformări Modificările sunt prezentate în fig Orez Schimbarea punctului de bază în modul de afișare MM TEXT Trebuie amintit că o astfel de mapare poate fi implementată în alte moduri Punctului de bază al ferestrei i se pot atribui coordonate ( , ), iar punctului de bază al ferestrei i se pot atribui coordonate (-dcHeight*WExtx/VExtx/ , -dcWidth*WExty/VExty/ ) Din punct de vedere matematic, aceste două metode sunt echivalente, dar a doua metodă duce la erori de rotunjire puțin mai mari În alte moduri de afișare, direcția implicită a axei y este diferită de direcția acesteia în modul MM TEXT Ei folosesc direcția tradițională pentru sistemul de coordonate carteziene - de jos în sus În acest caz, în spațiul de coordonate al dispozitivului este afișat doar al doilea cadran, cu valori x pozitive și valori negative y Puteți folosi în continuare fragmentul de mai sus pentru a mapa punctul de bază al ferestrei la centrul spațiului de coordonate al dispozitivului Dar dacă doriți doar să mapați primul cadran la spațiul dispozitivului, procedați astfel: SetW ndowOrgEx(hDC NULL); SetV ewport rgEx(hDC, dcHelght NULL); Aceeași orientare pe axa y este utilizată în limbajul PostScript Diferențele sunt prezentate în fig Orez Schimbarea punctului de bază în alte moduri de afișare În modurile MM ISOTROPIC și MM ANISOTROPIC, aplicația determină direcțiile axelor în mod arbitrar Cu toate acestea, trebuie să acționați cu atenție, deoarece GDI Sistemul de coordonate mondial onorează setările la implementarea primitivelor grafice, cu o singură excepție: GDI scoate întotdeauna linii de text într-o singură direcție, cu excepția cazului în care contextul dispozitivului este în modul grafic avansat Chiar dacă axa x este de la dreapta la stânga, șirurile de text sunt scoase în continuare de la stânga la dreapta, fără răsturnarea glifului Acest lucru poate fi destul de complicat dacă o aplicație folosește moduri de afișare pentru a oglindi documentele despre axa y Problema este rezolvată fie prin simularea reflectării textului într-un context compatibil, fie prin transformări ale lumii în sistemul de coordonate mondial Alte funcții ale ferestrelor și ferestrelor API-ul Win oferă mai multe funcții de ajutor care facilitează gestionarea setărilor curente ale ferestrei și ferestrei de vizualizare Funcția GetMapMode returnează informații despre modul de mapare curent Funcțiile OffsetWindowOrgEx și OffsetViewportOrgEx modifică poziția punctului de bază al unei ferestre sau ferestrei de vizualizare Acestea sunt utile în special pentru mutarea treptată a ferestrei și a ferestrei de vizualizare (de exemplu, când se manipulează mesaje de defilare) Funcțiile Scale-WindowExtEx și ScaleViewportExtEx scalează dimensiunile ferestrelor și ferestrelor de vizualizare printr-un factor fracțional, care poate fi util atunci când se gestionează cererile de scalare Sistemul de coordonate mondial Dintr-o perspectivă profesională de programare grafică, afișarea ferestrei/vizualizării și diferitele moduri de afișare sunt un compromis adânc înrădăcinat în arhitectura originală Winl GDI API, când procesoarele rulau la MHz și memoria era scumpă Drept urmare, arhitectura și implementarea GDI a trebuit să caute soluții cât mai simple și eficiente Mai jos sunt enumerate câteva dintre deficiențele arhitecturii spațiului de coordonate de paginare О Coeficienți fracționari la afișarea unei ferestre în fereastra de vizualizare Atât fereastra, cât și fereastra sunt descrise prin numere întregi, astfel încât coeficienții fracționali sunt utilizați la maparea ferestrei la fereastra Valorile fracțiilor sunt ușor de calculat folosind înmulțirea întregului, urmată de împărțire Cu toate acestea, numerele întregi rezultate sunt selectate dintr-un set limitat, ceea ce poate duce la o pierdere de precizie De exemplu, după cum se arată mai sus, în modul MM ISOTROPIC, poate exista o discrepanță între factorii de scară de-a lungul axelor O Implementare incompletă Ieșirea textului nu urmează semantica reflecției despre axa y Cu alte cuvinte, dacă aplicația indică axa x de la dreapta la stânga, șirurile de text sunt încă afișate de la stânga la dreapta О Set limitat de transformări Maparea de la fereastră la fereastră vă permite să efectuați transformări de compensare, scalare și oglindă Capitolul Sisteme de coordonate și transformări reflexie calica Rotația și înclinarea nu sunt acceptate și, fără suport direct din partea GDI, sunt foarte greu de implementat În Windows NT/ , a fost creat un nou sistem de coordonate logice, coordonate mondiale, pentru a rezolva aceste probleme În spațiul de coordonate mondial, coordonatele sunt încă specificate ca numere întregi pe de biți, spre deosebire de alte sisteme grafice (cum ar fi PostScript) care folosesc numere reale La maparea punctelor din sistemul de coordonate mondial la spațiu de coordonate de pagină, devine posibil să se utilizeze transformări mai generale Transformări afine Există diferite tipuri de transformări de la un sistem de coordonate la altul De exemplu, o transformare în perspectivă mapează obiectele D pe o suprafață D, în timp ce o transformare fisheye simulează distorsiunea obiectelor văzute printr-o lentilă specială Transformările suportate în Windows NT/ aparțin clasei transformărilor afine bidimensionale O transformare afină mapează linii paralele la linii paralele și punctele finale la punctele finale O transformare afină bidimensională este definită de șase numere care formează o matrice x În API-ul Win , astfel de matrici sunt definite de structura XFORM typedef struct XFORM { FLOAT EMII; FLOAT eM : FLOAT eM ; FLOAT eM : FLOAT eDx; FLOAT eDy; }XFORM: Transformarea afină definită de aceste numere transformă punctul (x, y) în (x', y), unde x' = eMP * x + eM * y + eDx; y' = eM * x + eM * y + eDy: La prima vedere, arată ca formule de mapare fereastră-la-vizor, dar, în realitate, transformarea afină are mai multe capacități Maparea fereastră la fereastră utilizată în sistemul de coordonate a paginii poate fi considerată ca o clasă specială de transformări afine în care eM și eM sunt zero Transformările afine vă permit să efectuați următoarele operații О Maparea identității Definit de matricea { , , , , , }; x' = x, y' = y Despre Offset Determinată de matricea { , , , ,b/g/d/}, x'e x + dx; y' = y + dy Despre scalare Este determinat de matricea {mx, , my, }, x' = mx*x; y' = tu*y Oglindă reflectare Determinată de matricea {- , , ,- , , }, x' = -x; y' în = -y- Sistemul de coordonate mondial O, întoarce-te Definit de matricea {cos( ), sin(O), -sin( ), cos(O), , } x' = = cos( ) xx - sin( ) xz/; z/' = sin( ) xx + cos( ) x y Punctul (x,z/) este rotit cu un unghi și relativ la punctul de bază în sens invers acelor de ceasornic Oh Shift Definit de matricea {l,s, , , , } x' = x + sxz/, z/'=z/ Coordonatele x sunt deplasate cu o cantitate proporțională cu y O Operații combinate Matricele mai multor transformări afine sunt combinate prin operația de multiplicare a matricei și formează o nouă transformare afină Șase transformări de bază sunt ilustrate în fig Identitate Părtinire Scalare Orez Transformări afine bidimensionale simple Transformarea, translația, scalarea și reflectarea identice au fost deja demonstrate atunci când se mapa coordonatele paginii la coordonatele dispozitivului, deși de data aceasta folosim liber numere reale Rotirea este o operațiune nouă și foarte utilă Rotirea sistemului de coordonate în jurul punctului de bază se realizează conform următoarelor formule: x' = cos(theta) * x - sin(theta) * y y' = sln(theta) * x + cos(theta) * y Problema generală a rotației în jurul unui punct arbitrar (xO,y(Y) este rezolvată în trei etape Mai întâi se realizează o deplasare (-xO-yO), apoi o rotație și, în final, o deplasare inversă (xO,y() J) Transformarea finală arată astfel: x' = cos(theta) * (x-xO) - sin(theta) * (y-yO) + xO y' = sin(theta) * (x-xO) + cos(theta) * (y-yO) + yO În timpul forfecării (deformarea transversală), la o coordonată se adaugă o valoare proporțională cu valoarea celeilalte coordonate Deplasarea poate fi efectuată și de-a lungul ambelor coordonate, astfel încât formulele generale de deplasare arată astfel: x' = x + h * y y* = g * x + y Transformările afine au o serie de proprietăți interesante, datorită cărora sunt utilizate pe scară largă în grafica computerizată înţelegere Capitolul Sisteme de coordonate și transformări Cunoașterea acestor proprietăți vă va ajuta să înțelegeți mai bine cum se transformă geometria definită de aplicație atunci când sunt utilizate aceste transformări De asemenea, oferă o perspectivă asupra implementării interne a transformărilor de către motorul grafic A Transformările afine păstrează linii drepte O linie dreaptă se mapează la o linie dreaptă, un triunghi se mapează la un triunghi, iar un poligon se mapează la un poligon Pentru a implementa transformări afine pentru linii și poligoane, motorul grafic trebuie doar să calculeze mapările lor de vârf și apoi să deseneze linii sau segmente de conectare A Transformările afine păstrează paralelismul (liniile paralele se mapează la liniile paralele) Deci, un paralelogram se mapează la un paralelogram, deși dreptunghiurile nu se mapează întotdeauna cu dreptunghiuri, iar pătratele nu se mapează neapărat cu pătrate A Transformările afine păstrează elipsele O transformare afină mapează întotdeauna o elipsă la o elipsă, deși un cerc nu se mapează întotdeauna la un cerc Prin intermediul GDI API sunt definite doar cercuri și elipse ortogonale, ale căror axe sunt paralele cu axele x și z, dar cu ajutorul transformărilor afine este posibilă trasarea unei elipse arbitrare pe suprafața dispozitivului A Transformările afine păstrează curbele Bezier Ca și în cazul liniilor și poligoanelor, tot ce rămâne pentru GDI este să aplice transformări afine la vârfurile care definesc curba Bezier și apoi să le combine într-o curbă Bezier transformată în coordonatele dispozitivului О O transformare afină este determinată în mod unic de trei vârfuri ale vectorilor necoliniari p, q, rB în sistemul de coordonate original și trei vârfuri ale vectorilor necoliniari p\q\r' în sistemul de coordonate rezultat Cu alte cuvinte, există o singură transformare afină care mapează p, q, r, respectiv, la p\q', r' Rețineți că toate mapările de la coordonatele paginii la coordonatele dispozitivului suportate de GDI sunt definite în mod unic de două puncte în fiecare dintre sistemele de coordonate Proprietățile enumerate ale transformărilor afine sunt reflectate în implementarea primitivelor grafice GDI utilizate în Windows NT/ După cum sa menționat mai sus, un cerc sau o elipsă, ca rezultat al unei transformări afine, este mapată la un cerc sau elipsă, care poate să nu fie ortogonală cu axele În grafica computerizată, este foarte dificil să desenezi eficient o elipsă arbitrară Cum abordează motorul grafic această sarcină? Fiecare elipsă este împărțită în patru curbe Bezier, care sunt ușor afișate și reproduse în sistemul de coordonate al dispozitivului ca curbe Bezier Deoarece transformările afine sunt numere reale în loc de fracții utilizate atunci când se afișează o fereastră în fereastra de vizualizare, operațiunile interne ale motorului grafic Windows NT/ folosesc numere în virgulă fixă, făcând calculele mai precise Din punct de vedere matematic, o transformare afină este o funcție t: R x R-> R x R sub forma t (x) \u d Ax + b, unde A este inversată Sistemul de coordonate mondial a x matrice și b este un punct în R x R Mulțimea tuturor transformărilor afine ale lui R x R se notează A( ) Se poate demonstra că mulţimea transformărilor afine A( ) formează un grup în raport cu mulţimea operaţiilor compoziţionale Termenul „grup” în acest caz este conceptul de algebră abstractă și este definit ca un set arbitrar de operații pe un anumit câmp, care are proprietățile de închidere, existența unei operații identice (unității) și inverse și asociativitatea Pentru transformările afine, aceste proprietăți sunt definite după cum urmează Oh, apropiere Compoziția oricăror două transformări afine este, de asemenea, o transformare afină Dacă M(x) = A x x + N și t (x) = A x x + b , atunci (£ x £ )( r) = (A x A ) x x + (A x b + bl) О Prezența transformării identității Există o transformare afină identică (singura) і(х) sub care pentru orice transformare afină t(x) afirmațiile (і х t)(x) = t(x) și (t х і)(х) = t( X) De fapt, i(x) = I x x + , unde I este matricea de identitate x О Prezența transformării inverse O transformare afină este de asemenea afină Inversa lui t(x) = Axx + b este transformarea ( /A) xx - ( /A) x b Despre asociativitate Compoziția transformărilor afine este asociativă; cu alte cuvinte, pentru orice transformări afine t , t și t condiția (t x t ) x t = t x (t x t ) este îndeplinită La prima vedere, aceste concepte matematice par o abstractizare, dar sunt extrem de utile în grafica computerizată Nu este neobișnuit ca o aplicație să definească transformări multiple care sunt combinate într-o transformare finală În special, această capacitate este utilizată intern de motorul grafic pentru a combina două transformări (de la coordonatele lumii la coordonatele paginii și de la coordonatele paginii la coordonatele dispozitivului) Amintiți-vă că maparea de la spațiul de coordonate a paginii la spațiul de coordonate al dispozitivului este, de asemenea, un caz special de transformări afine Transformările inverse facilitează inversarea hărții de la coordonatele paginii sau ale dispozitivului la coordonatele lumii În special, această proprietate este utilizată pentru a mapa coordonatele evenimentului mouse-ului la spațiul de coordonate mondial Motorul grafic folosește același cod de program, dar numai pentru transformarea inversă Funcții World Transform în Win API Destul de raționament abstract despre transformările afine Acum ne referim la suportul API-ului Win pentru sistemul de coordonate mondial și transformările lumii În mod implicit, contextul dispozitivului rulează în ceea ce este cunoscut sub numele de modul grafic compatibil (adică compatibilitate cu semantica GDI pe biți) În modul compatibil, coordonatele mondiale nu sunt acceptate, iar singurul sistem de coordonate logic este sistemul de pagini Dacă o aplicație dorește să permită utilizarea coordonatelor mondiale, trebuie Capitolul Sisteme de coordonate și transformări comutați contextul dispozitivului în modul grafic apelând funcția Set-GraphicsMode(hDC, GM ADVANCED), implementată numai în Windows NT/ Ca rezultat al apelului, contextul dispozitivului menține două niveluri de spațiu de coordonate logice - coordonatele lumii și ale paginii, precum și o matrice de transformare Informațiile despre modul grafic curent sunt returnate de funcția GetGraphicsMode(hDC) Pentru a reveni la modul compatibil, completați matricea cu date de transformare a identității și apelați SetGraphicsMode(hDC, GM COMPATIBLE) De asemenea, puteți utiliza funcțiile SaveDC și RestoreDC Comutarea contextului dispozitivului în modul GM ADVANCED nu se limitează la activarea suportului pentru coordonatele mondiale De asemenea, are un impact semnificativ asupra implementării primitivelor grafice utilizate în GDI Diferențele dintre cele două moduri sunt enumerate în Tabelul Tabelul Diferențele dintre modurile grafice GDI Regiunea GM COMPATIBILĂ GM ADVANCED Sisteme de coordonate logice Coordonatele paginii Coordonatele lumii și ale paginii Platformă Windows / , Windows NT/ Windows NT/ Direcția de ieșire a textului Textul este întotdeauna scos de la stânga la dreapta de sus în jos, chiar dacă direcția axelor a fost schimbată prin schimbarea modului de afișare Direcția textului poate fi schimbată doar prin schimbarea unghiului și orientării fontului logic sau a unui context de dispozitiv compatibil Șirurile de text sunt redate în funcție de transformările și afișările în vigoare Scalare text Numai fonturile TrueType sunt scalate Fonturile TrueType și fonturile vectoriale sunt scalate GDI încearcă să ofere o calitate optimă de ieșire pentru fonturile bitmap, dar rezultatele nu sunt garantate Dreptunghiuri Marginile drepte și inferioare sunt excluse din dreptunghi Marginile drepte și inferioare sunt incluse în dreptunghi Direcția arcelor Arcurile sunt desenate în direcția specificată de funcția SetArcDirection În coordonatele logice, arcele sunt întotdeauna desenate în sens invers acelor de ceasornic Afișarea arcurilor Mapările nu sunt luate în considerare la afișarea arcurilor Arcurile sunt scoase în funcție de transformări și mapări Sistemul de coordonate mondial Într-un context de dispozitiv, conversia din lume în pagină este inițializată implicit cu o matrice de identitate Următoarele funcții sunt utilizate pentru a modifica transformarea curentă: BOOL SetWorldTransform(HDC hDC CONST XFORM * IpXform); BOOL ModificăWorldTransform(HDC hDC, CONST XFORM * IpXformm DWORD iMode); Funcția SetWorldTransform înlocuiește pur și simplu atributul de transformare în contextul dispozitivului cu noua transformare specificată de structura XFORM Vă rugăm să rețineți: nu fiecare șase numere de tip FLOAT definește transformarea afină corectă Definiția formală a transformărilor afine necesită ca matricea x formată din numerele eMI, eM , eM și eM să fie inversabilă; adică trebuie îndeplinită condiţia eMI x eM != eM x eM De exemplu, următoarea încercare va eșua: XFORM xm = { , }; SetGraphicsMode(hDC, GM ADVANCED); rezultat BOOL = SetWorldTransform(hDC & xm); Eroare DWORD = GetLastErrorO; Matricea xm definește transformarea x' = x + y + și y' = x + y + , deci y' = x' - Se dovedește că toate punctele sistemului de coordonate mondial sunt afișate pe o singură linie y = x + sisteme de coordonate de pagină Această conversie nu este reversibilă și nu oferă o potrivire : , deci nu este permisă În acest exemplu, SetWorldTransform va returna FALSE așa cum v-ați aștepta, dar în mod ciudat, GetLastError returnează (ERROR SUCCESS) chiar și pe Windows NT/ Cu toate acestea, GDI este în general prost în a explica cauzele erorilor Apelul către SetWorldTransform eșuează și atunci când contextul dispozitivului este în modul grafic GM SETCOMPATIBLE sau programul rulează pe Windows / Când este apelat ModifyWorldTransform, parametrul iMode ia una dintre cele trei valori Când parametrul IMode este egal cu MTW IDENTITY, transformarea este convertită în formularul de identitate Dacă iMode este MTW LEFTMULTIPLY, transformarea curentă este lăsată înmulțită cu *lpXform În cele din urmă, dacă parametrul iMode este MTW RIGHTMULTIPLY, transformarea curentă este înmulțită corect cu *lpXform În acest caz, înmulțirea se referă la executarea secvențială a două transformări, formând o nouă transformare GDI distinge între înmulțirea la stânga și la dreapta deoarece multiplicarea prin transformare nu este întotdeauna comutativă Spre deosebire de matematica întregului, în domeniul transformărilor a x b nu este întotdeauna egal cu b x a Funcția GetWorldTransform este utilizată pentru a obține informații despre transformarea curentă De fapt, acesta este tot suport pentru lumea uimitoare a transformărilor din API-ul Win În rest, vă puteți baza pe vechiul manual de geometrie analitică, pe o carte despre teoria graficii pe computer - sau pur și simplu citiți mai departe Folosind World Transforms Coordonatele lumii și transformările lumii, datorită transformărilor afine bidimensionale, sunt de mare folos în grafica computerizată Capitolul Sisteme de coordonate și transformări Din păcate, suportul lor în API-ul Win este foarte limitat Pentru a rezolva chiar și probleme practice simple, trebuie să-ți strângi creierul De exemplu, cum să rotiți un obiect în jurul unui punct arbitrar (x, z/) sau să calculați transformări care afișează o imagine dreptunghiulară pe fața unui cub tridimensional? În această secțiune, vom crea o clasă C++ Kaffine care conține destul de multe metode utile Declarația clasei Kaffine este prezentată în Lista Lista Declarație de clasă de transformare afină Kaffine clasa Kaffine { public: XFORM m xm: KaffineO { resetO; void resetO: BOOL SetTransform(const XFORM & xm); BOOL Combină (const XFORM & b); BOOL Inversare(void); BOOL Translate(FLOAT dx, FLOAT dy): BOOL Scale(FLOAT sx, FLOAT dy); BOOL Rotire(FLOAT unghi FLOAT x = FLOAT y = ): BOOL MapTri(FLOAT pxO FLOAT pyO, FLOAT qxO, FLOAT qyO FLOAT rxO, FLOAT ryO): BOOL MapTri(FLOAT pxO FLOAT pyO, FLOAT qxO, FLOAT qyO FLOAT rxO FLOAT ryO FLOAT pxl FLOAT pyl, FLOAT qxl, FLOAT qyl, FLOAT rxl FLOAT ryl): }: Clasa este concepută să funcționeze cu o transformare afină, reprezentată de o structură Win XFORM, care este stocată într-o singură variabilă de clasă m xm Primele trei metode repetă funcționalitatea Win API: Resetare resetează matricea la aceeași stare, SetTransform copiază datele din structura XFORM și Combine combină transformări succesive Metoda Kaffine: :Invert înlocuiește transformarea curentă cu inversa Cele trei metode care îl urmează sunt de fapt instrucțiuni PostScript Metoda Translate completează transformarea curentă cu o operație de schimbare, metoda Scale modifică scara de-a lungul a două axe, iar metoda Rotate adaugă rotația în jurul unui punct arbitrar (x , y ) la transformarea curentă Vă puteți gândi la fiecare dintre aceste trei metode ca efectuând o transformare simplă (deplasare, scară sau rotație) și să o combinați cu transformarea curentă Două metode MapTri sunt concepute pentru a rezolva o problemă comună - găsirea unei transformări afine care mapează trei vârfuri ale vectorilor necoliniari pO, qO, rO la un alt triplet necoliniar p , q și r Acest lucru se face în două Sistemul de coordonate mondial etapă Mai întâi trebuie să găsiți două transformări care mapează punctele ( ), ( ) și ( ) în două triplete Această problemă este mult mai simplă decât cea originală și este rezolvată prin prima metodă MarTri Prima transformare este apoi inversată și combinată cu a doua; rezultatul este transformarea finală Ceea ce se întâmplă poate fi gândit ca o mapare p , q și r în ( , ), ( , ) și ( , ) urmată de o mapare bp , q , r O implementare a clasei Kaffine cu verificarea erorilor este prezentată în Listarea Lista - Implementarea clasei de transformări afine Kaffine #define STRICT #define WIN LEAN AND MEAN #include # nclude # includeți „afflne h” // Tranziția la transformarea identității void Kaffine::Reset() { m xm eMll = : m xm eM = : m xm eM = : m xm eM = : m xm eDx= : m xm eDy = : } // Dacă transformarea corespunde criteriilor de validare // copiați-l BOOL Kaffine::SetTransform(const XFORM & xm) { dacă ( xm eMll * xm eM == xm eM * xm eM ) returnează FALS; m xm=xm: returnează TRUE: // transform = transform * b BOOL Kaffine::Combină (const XFORM & b) dacă ( b eMll * b eM == b eM * b eM ) returnează FALS; XFORM a=m xm: // // m xm eMll = a eMll * b eMll + a eM * b eM ; m xm eM = a eMll * b eM + a eM * b eM : Capitolul Sisteme de coordonate și transformări Lista Continuare m xm eM » a eM * b eMI + a eM * b eM : m xm eM » a eM * b eM + a eM * b eM : m xm eDx - a eDx * b eMI + a eDy * b eM + b eDx; m xm eDy - a eDx * b eM + a eDy * b eM + b eDy: returnează TRUE: } // transformare • / transformare // I = A * x + B // Іпѵ(М) = Іпѵ(А) * x - Inv(A) * В BOOL Kaffine::Inversare(void) { FLOAT det = m xm eMll * m xm eM - m xm eM * m xm eM : dacă (det== ) returnează FALSE: XFORM vechi = m xm: m xm eMll = vechi eM /det: m xm eM = - old eM / det: m xm eM = - old eM / det: m xm eM = vechi eMll/det; m xm eDx = - ( m xm eMll * old eDx + m xm eM * old eDy ): m xm eDy = - ( m xm eM * old eDx + m xm eM * old eDy ): returnează TRUE: } BOOL Kaffine::Translate(FLOAT dx, FLOAT dy) { m xm eDx +- dx; m xm eDy +- dy: returnează TRUE; } BOOL Kaffine;:Scaie(FLOAT sx FLOAT sy) { dacă ((sx==O) || (sy==O) ) returnează FALSE: m xm eMll *= sx: m xm eM *= sx: m xm eM *= sy: m xm eM *= sy: m xm eDx *= sx; m xm eDy *= sy: returnează TRUE: Sistemul de coordonate mondial BOOL Kaffine::Rotate(FLOAT unghi FLOAT xO, FLOAT yO) { XFORM xm: Traduceți(-xO, -yO): // Mută originea în (xO yO) rad dublu = unghi * ( , / ): xm eMll » (FLOAT) cos(rad): xm eM = (FLOAT) sln(rad): xm eM " - xm eM : xm eM = xm eMll: xm eDx = : xm eDy = : Combină (xm): //Rotire Translate(xO yO): // Pune originea la loc returnează TRUE: } // Găsiți transformarea care mapează ( ) ( ) ( ) // respectiv în r q G BOOL Kaffine::MapTri(FLOAT pxO FLOAT pyO FLOAT qxO, FLOAT qyO FLOAT rxO FLOAT ryO) { // pxO = dx, qxO = mll + dx, rxO = m + dx // pyO = dy qyO = ml + dy ryO = m + dy m xm eMll = qxO - pxO; m xm eM "qyO - pyO: m xm eM e rxO - pxO; m xm eM "ryO - pyO: m xm eDx » pxO: m xm eDy = pyO: returnează m xm eMll * m xm eM != m xm eM * m xm eM : } // Găsiți transformarea care redă p qO rO // respectiv în pl ql rl BOOL Kaffine::MapTri(FLOAT pxO FLOAT pyO FLOAT qxO FLOAT qyO, FLOAT rxO FLOAT ryO, FLOAT pxl, FLOAT pyl FLOAT qxl, FLOAT qyl FLOAT rxl FLOAT ryl) { Dacă ( ! MapTri(pxO pyO qxO qyO rxO ryO) ) returnează FALSE: InvertO: // Convertește pO qO rO în ( , ) ( , ) ( , ) Kaffine mapl; Dacă (! mapl MapTri(pxl pyl qxl qyl rxl ryl) ) returnează FALSE: return Comb ne(mapl m xm): // Apoi la pl rl ql Capitolul Sisteme de coordonate și transformări Transformările afine sunt utilizate pe scară largă în alte sisteme grafice (de exemplu, în PostScript) Clasa de bază Kaffine face mult mai ușoară conversia exemplelor PostScript spectaculoase în GDL Un exemplu simplu este ilustrat în Figura - când sunt afișate linii întrerupte cu o modificare permanentă a transformării, pe ecran apare un model interesant void Transform DottedLine(HDC hDC int lățime, int înălțime) { Kaffine af: // Sistem de coordonate carteziene cu originea centrului SetMapMode(hDC MM ANISOTROPIC): SetViewportExtEx(hDC, ,- , NULL); SetViewportOrgEx(hDC, lățime/ , înălțime/ , NULL); SetGraphicsMode(hDC, GM ADVANCED); pentru (int i= ; i ( , ) pentru (int x= ; x m width - rect right ) x = m lățime - rect right: SetScrol!Pos(m hWnd SB HORZ x FALSE): y -= rect bottom/ ; Dacă ( y mjielght - rect bottom ) y=mjielght-rect bottom: SetScrol IPosCmJiWnd, SB VERT y FALS): // Redesenează Inval dateRect(mJiWnd, NULL TRUE); ::UpdateW ndow(m hWnd): } LRESULT KScrollCanvas::WndProc(HWND hWnd UINT uMsg WPARAM wParam LPARAMIParam) { comutare(uMsg) Capitolul Sisteme de coordonate și transformări Lista - Continuare caz WM CREATE: m hWnd = hWnd: OnCreate(): returnează ; case WM-SIZE: SetScrollBar(SB HORZ, m width, LOWORD(IParam)); SetScrollBar(SB VERT, m he ght, HIWORDOParam)); returnează : caz WM PAINT: { PAINTSTRUCT ps: HDC hDC = Beg nPa nt(m hWnd, &ps): SetW ndow rgEx(hDC, , , NULL): SetV ewportOrgEx(hDC, - GetScrollPos(hWnd SB HORZ), - GetScrollPos(hWnd, SB VERT), NULL): OnDraw(hDC, & ps rcPaint); EndPa nt(m hWnd, &ps): } returnează : cazul WM RBUTTONDOWN: OnZoom( LOWORD( Param), HIWORD( Param) ): returnează : cazul WM LBUTTONDOWN: OnZoom( LOWORD( Param), HIWORDC Param), ): returnează : caz WMJHSCROLL: OnScroll(SB HORZ, LOWORD(wParam), HIWORD(wParam)): returnează : caz WM-VSCROLL: OnScrol (SB VERT, LOWORD(wParam), HIWORD(wParam)): returnează : caz WM-TIMER: nT mer(wParam, IParam): returnează : caz WM MOUSEMOVE: OnMouseMove(wParam, IParam); returnează : caz WM-DESTROY: OnDestroyO; returnează : Exemplu de program: derulare și mărire implicit: returnează KCanvas::WndProc(hWnd uMsg, wParam, Param): } } Funcția KScrollWindow: :WndProc controlează modul în care fereastra gestionează mesajele Pentru unele mesaje, procesarea se reduce la apelarea unei funcții virtuale, care permite claselor derivate să proceseze aceste mesaje fără a reimplementa funcția WndProc Pentru mesajul WM SIZE, barele de defilare sunt actualizate pentru a reflecta modificările dimensiunii ferestrei Pentru mesajul WM PAINT, programul citește pozițiile barelor de defilare și folosește valorile rezultate pentru a muta punctul de bază al ferestrei de vizualizare într-o poziție dincolo de colțul din stânga sus al ecranului Rețineți că, atunci când pozițiile barei de derulare sunt diferite de zero, o parte a pânzei virtuale este în afara ecranului în stânga și sus Pe baza acestui lucru, mutăm punctul de bază al ferestrei de vizualizare în poziția off-screen dată de coordonate (-poziția barei de derulare verticale, -poziția barei de derulare orizontale) Odată făcută selecția corectă, metoda OnDraw nu mai trebuie să-și facă griji cu privire la defilare La procesarea unui mesaj WM LBUTTONDOWN, imaginea din fereastră este mărită la punctul de clic, iar la procesarea unui WM RBUTTONDOWN, imaginea este redusă Bara de defilare generează mesaje WM VSCROLL și WM HSCROLL gestionate de o singură funcție OnScroll Această funcție (nu este afișată în listă) calculează o nouă poziție de defilare în funcție de codul transmis către LOWORD(wParam), o normalizează la un interval valid, actualizează poziția glisorului și apoi derulează fereastra cu funcția ScrollWindow Funcția Win ScrollWindow defilează conținutul unei ferestre prin deplasarea buffer-ului ecranului Partea nedesenată deschisă este adăugată în regiunea actualizată a ferestrei și redesenată în timpul procesării ulterioare WM PAINT Du-te la joc în clasa KScrollCanvas Utilizarea clasei KScrollCanvas va fi demonstrată folosind un program simplu care desenează o tablă go Apropo, go este numele japonez pentru cel mai interesant și foarte vechi joc chinezesc „weichi” (literal, „joc de mediu”) Lista arată declarația clasei KWeiQiBoard Clasa derivată implementează metodele virtuale OnDraw și OnCommand, care oferă rezultate specializate și procesare a comenzilor de meniu Lista - Declarație de clasă KWeiQiBoard - caz de utilizare clasa KScrollCanvas clasa KWeiQiBoard : KScrollCanvas public { virtual vold OnDraw(HDC hDC, const RECT * rcPaint); virtual BOOL OnCommand(WPARAM wParam, LPARAM Param): int m gr ds ; cm http://www go sp ru - Notă nepee Capitolul Sisteme de coordonate și transformări Lista - Continuare int mjjnitsize ; char*m stones; int margin(void) const; // Margini de la cele patru margini ale pânzei int pos(int n) const; // Poziția celei de-a n-a intersecții public; KWeiQiBoardO { m grids= ; // Tabla x mjjnitsize = ; // de pixeli între intersecții m stones = "B W ": // Exemplu SetSize(pos(m grids-l)+margin(), pos(m grids-l)+margin(), m unitsize mjjnitsize); } }: Rezultatul este prezentat în fig Imaginea a fost mărită și derulată în colțul din dreapta jos al tablei Orez Go board randat folosind clasa KScrollCanvas Rezultate Acest capitol se concentrează pe cele patru sisteme de coordonate suportate de API-ul Win - lume, pagină, dispozitiv și fizic Am luat în considerare transformările lumii care reprezintă Rezultate ordonate de la sistemul de coordonate mondial la cel de pagină; diverse moduri de afișare care controlează transformarea coordonatelor din sistemul de paginare în sistemul de coordonate al dispozitivului; în plus, a fost descrisă relația dintre sistemul de coordonate al dispozitivului și sistemul de coordonate fizic Capitolul se încheie cu o descriere detaliată a transformărilor afine, proprietățile lor și unele operații, inclusiv compoziția și inversarea Materialul prezentat ilustrează clasa KScrollView, care acceptă scalarea și derularea Capitolul se încheie cu un exemplu simplu de utilizare a acestei clase Exemple de programe În acest capitol, sunt luate în considerare doar două exemple de programe (Tabelul ) Tabelul Capitolul Programe Descriere director de proiect Samples\Chapt \CoordinateSpace Studiul sistemelor de coordonate și al transformărilor afine Samples\Chapt \WeiQi Test program pentru clasa KScrollView cu suport pentru zoom și defilare Capitolul Pixeli Dintre toate operațiunile cu contexte de dispozitiv în Win GDI, cea mai dificilă este ieșirea unui singur pixel Desigur, nu este vorba doar despre schimbarea culorii unui pixel, ci mai degrabă despre înțelegerea completă a tuturor factorilor care afectează procesul de ieșire Sub condiția unei astfel de înțelegeri, ieșirea de linii, curbe, forme, raster și text nu va mai cauza dificultăți deosebite Capitolul a fost despre sisteme de coordonate, moduri de afișare și transformări; acest capitol acoperă obiectele GDI, manipulatoare, decuparea, culoarea și, în final, ieșirea unui singur pixel Obiecte GDI, manipulatoare și tabel de obiecte API-ul Win utilizează zeci de obiecte diferite (obiecte fișier, obiecte de sincronizare, obiecte GDI etc ), deși API-ul nu se bazează pe niciunul dintre limbajele de programare moderne orientate pe obiecte API-ul Windows a fost lansat în , când doar de programatori scriau C++ - cu mult înainte de ascensiunea fulgerătoare a limbajelor orientate pe obiecte în anii Un obiect într-un limbaj orientat pe obiect este o instanță a unei clase ai cărei membri (variabile și funcții de clasă) definesc datele și comportamentul obiectului Noile obiecte sunt inițializate cu funcții speciale de clasă numite constructori Alte funcții speciale numite destructori sunt folosite pentru a distruge obiecte Astfel, un obiect într-un limbaj orientat pe obiecte este asociat cu un anumit set de date și funcții care efectuează anumite operații Definiția clasei specifică care dintre variabile și funcții sunt publice, protejate sau private Acest lucru atinge unul dintre obiectivele importante - mascarea implementării Obiecte GDI, manipulatoare și tabelul de obiecte Deși API-ul Win nu este orientat pe obiecte, interfața în felul său încearcă să rezolve aceleași probleme pe care limbajele orientate pe obiecte au fost concepute pentru a le rezolva, și anume, mascarea implementării și tipurile de date abstracte API-ul Win își maschează obiectele într-o măsură mai mare decât limbajele orientate pe obiecte Când lucrați cu obiecte API Win , o aplicație nu le cunoaște dimensiunea sau locația în memorie API-ul Win acceptă funcții speciale pentru crearea de obiecte de diferite tipuri, care sunt diferite de constructorii limbajului C++ Obiectele C++ sunt create în doi pași: în primul rând, memoria este alocată pentru obiect, iar apoi obiectul este inițializat cu un constructor Prin urmare, o aplicație care utilizează un obiect trebuie să știe exact câtă memorie ocupă obiectul și unde se află în memorie Funcțiile Win pentru crearea obiectelor Win ascund atât dimensiunea, cât și adresa obiectului Mai mult, aplicația nici măcar nu primește un pointer către obiect; i se dă doar un mâner de obiect Manipulatoarele Win API sunt numere care identifică în mod unic o BeKTbiWin , iar metoda de identificare este cunoscută doar de sistemul de operare Conceptul de tipuri de date abstracte este reprezentat în C++ prin clase abstracte, clase concrete și funcții virtuale O clasă abstractă definește comportamentul general al unei clase folosind funcții virtuale Aceeași clasă abstractă poate fi implementată diferit de mai multe clase concrete, fiecare oferind o implementare diferită a funcțiilor virtuale Obiectele claselor concrete pot fi interpretate ca obiecte ale unei clase abstracte ale cărei apeluri de funcții sunt efectuate printr-un tabel de funcții virtuale La o inspecție mai atentă, se dovedește că Win folosește destul de multe tipuri de obiecte abstracte De exemplu, tipul de obiect fișier este un tip abstract din care sunt derivate diferite tipuri de obiecte concrete Funcția CreateFile poate fi folosită pentru a crea fișiere, conducte, sloturi de e-mail, porturi de comunicație, console, directoare și dispozitive, toate returnând același tip de mâner Urmărirea funcției WriteFile arată că operația finală este efectuată de diferite fragmente legate de diferite părți ale sistemului de operare și chiar de drivere de dispozitiv, ceea ce este foarte asemănător cu utilizarea funcțiilor virtuale în C++ În domeniul GDI, un context de dispozitiv poate fi gândit ca un tip de obiect abstract Când creați sau obțineți un context de dispozitiv pentru o imprimantă sau un ecran, un context compatibil sau metafișier, obțineți întotdeauna același tip de handle de context Desigur, apelurile grafice generale pe un anumit pointer sunt gestionate de diferite funcții furnizate de GDI sau drivere de dispozitiv grafic prin tabelul de indicatori de funcție din structura dispozitivului fizic Pe scurt, există motive suficient de bune pentru a numi API-ul Win „bazat pe obiect” Acum să vedem cum sunt stocate obiectele GDI în Windows NT/ și cum sunt mapate mânerele și obiectele În același timp, vă veți familiariza cu un exemplu specific de implementare a Win GDI - desigur, nu singurul posibil Capitol? Pixeli Stocarea obiectelor GDI Obiectele C++ sunt de obicei stocate pe stivă, pe heap sau în altă parte definită de operatorul nou supraîncărcat De obicei, această locație este spațiul de adrese în modul utilizator, cu excepția cazului în care este un driver de dispozitiv în modul kernel Sistemul grafic Windows NT/ este împărțit în trei părți: DLL client în modul utilizator (gdi dll), motorul grafic în modul kernel (win k sys) și diverse drivere de dispozitiv care rulează de obicei în modul kernel Împărțirea implementării în două moduri complică oarecum arhitectura de stocare a obiectelor GDI Un obiect GDI stocat în întregime într-un spațiu de adrese în modul utilizator este accesibil doar în timp ce procesul care l-a creat este activ, deoarece fiecare proces are propriul spațiu de adrese în modul utilizator După o schimbare a procesului, adresa la care este stocat obiectul devine invalidă Cu această abordare, operațiunile GDI în motorul grafic în modul kernel puteau fi executate doar în contextul procesului din care a venit apelul Desigur, acest lucru ar împiedica procesul rapid de schimbare a sarcinilor, necesar pentru sistemele multitasking de astăzi Pe de altă parte, un obiect GDI stocat în întregime în spațiul de adrese în modul kernel este accesibil doar din spațiul de adrese în modul kernel Când se efectuează operații simple (cum ar fi setarea atributelor contextului dispozitivului), sistemul ar trebui să apeleze o funcție de sistem pentru a comuta procesorul în modul kernel, să execute câteva linii de cod de asamblare și apoi să revină la modul utilizator În Windows NT/ , un obiect GDI este de obicei stocat în două părți, un obiect în modul utilizator și un obiect în modul kernel Obiectul în modul utilizator oferă o execuție rapidă a operațiunilor, în timp ce obiectul în modul kernel stochează informații independente de proces Unele obiecte în modul kernel (de exemplu, obiectul context dispozitiv) conțin copii complete ale obiectelor lor în modul utilizator, sincronizate printr-un mecanism Pentru majoritatea obiectelor, GDI păstrează o structură de date de dimensiuni fixe în memorie În acest caz, utilizarea memoriei nu cauzează mari probleme Cu toate acestea, pentru obiectele regiunii și rasterele specifice dispozitivului, cantitatea de date stocată de GDI poate crește la o dimensiune semnificativă Structurile de date GDI în modul kernel sunt stocate în ceea ce este cunoscut sub numele de pool paginat Pe un sistem cu utilizator unic Windows NT/ , pool-ul paginat al nucleului nu depășește MB Având în vedere că memoria GDI internă are o dimensiune limitată și este partajată de toate aplicațiile din sistem, aplicațiile ar trebui să utilizeze resursele sistemului cu moderație și să evite crearea de regiuni mari și rastere dependente de dispozitiv Obiecte GDI, manipulatoare și tabelul de obiecte Tabel de obiecte GDI Informațiile despre obiectele GDI sunt stocate într-un tabel de sistem cu dimensiuni fixe numit tabelul de obiecte GDI Aici este necesar să acordați atenție mai multor puncte În primul rând, tabelul de obiecte GDI are o dimensiune fixă și nu se extinde dinamic așa cum s-ar putea aștepta Această soluție este simplă și eficientă, dar are unele limitări În prezent, pentru Windows NT/ , tabelul de obiecte GDI are o capacitate de de mânere În al doilea rând, tabelul de obiecte GDI este partajat de toate procesele și DLL-urile de sistem Desktopul, browserul, editorul de text și jocurile DirectX concurează pentru un set comun de manipulatoare GDI În Windows , interfața DirectX folosește un tabel separat Tabelul de obiecte GDI este stocat în spațiul de adrese al nucleului, ceea ce face ușor accesul din motorul grafic O copie numai pentru citire a acestui tabel este creată în spațiile de adrese ale tuturor proceselor care utilizează GDI NOTĂ - Pe serverele terminale, fiecare sesiune are propria copie a motorului grafic Windows și propria copie a managerului de ferestre (win k sys), astfel încât mai multe tabele de obiecte GDI pot fi prezente pe sistem Intrările din tabelul de gestionare GDI sunt structuri de octeți: typedef struct { void* pKernel: unsigned short nPid; nesemnat scurt nCount: nesemnat scurt nUnique: nesemnat scurt nType: void * pUser; }GdiTableEntry: Pentru fiecare obiect GDI, tabelul stochează un pointer către un obiect în modul kernel, un pointer către un obiect în modul utilizator, un ID de proces, un contor, un ID unic și un ID de tip Ce soluție îngrijită, elegantă! Câmpul nPid stochează ID-ul procesului care a creat obiectul (valoarea returnată dintr-un apel la GetCurrentProcessIdO) Fiecare obiect GDI creat de un proces utilizator este etichetat cu un ID de proces, care împiedică alte procese să utilizeze handle-uri GDI Având în vedere un mâner de obiect, GDI poate verifica cu ușurință dacă obiectul a fost creat de procesul curent Încercările de a utiliza obiecte GDI create de alte procese eșuează Excepțiile sunt obiectele GDI standard, cum ar fi creionul negru, pensula albă și fontul de sistem, care sunt selecțiile implicite în contexte de dispozitiv noi Ar fi prea risipitor să creați copii ale obiectelor standard în fiecare proces In loc de asta Capitol? Pixeli obiectele standard sunt create o singură dată în sistem și li se atribuie un ID de proces de zero Managerul de activități raportează că ID-ul zero corespunde procesului de așteptare pasivă (inactiv) Obiectele GDI nule sunt disponibile pentru toate procesele Câmpul nCount conține un număr de selecție (sau număr de referințe) care împiedică ștergerea obiectelor afectate sau asigură că unele obiecte pot fi selectate o singură dată în contexte Din păcate, utilizarea câmpului nCount este în mare măsură limitată și, în prezent, este la latitudinea aplicațiilor utilizatorului să țină evidența când obiectele pot fi șterse Poate de cel mai mare interes este domeniul nUnique După cum sa menționat mai sus, obiectele GDI sunt stocate într-un singur tabel După ce un obiect este creat, utilizat și șters, intrarea corespunzătoare din tabel este eliberată și ulterior alocată unui alt obiect Să presupunem că programul a salvat mânerul primului obiect și a decis să-l folosească; ce se va intampla? Pe Windows NT/ , o astfel de încercare va eșua aproape sigur din cauza câmpului nUnique Acest câmp este împărțit într-un contor de reutilizare de biți și un cod de tip de biți Contorul este inițializat la zero și incrementat de fiecare dată când este creat un nou obiect GDI în intrarea dată în tabel Există un mecanism special care asigură utilizarea uniformă a elementelor de masă Prin urmare, manipulatorul va trece verificarea unicității numai dacă numărul de elemente create în acest element de tabel este un multiplu de și tipurile de obiecte se potrivesc Câmpul nType stochează o etichetă de tip intern care este convertită în tipul de obiect GDI returnat de funcția GetObjectType Manipulator de obiecte GDI În MSDN, un handle este definit ca o variabilă care identifică în mod unic un obiect sau o referință indirectă la o resursă a sistemului de operare În zilele noastre, se crede că un programator ar trebui să se mulțumească cu o astfel de definiție abstractă și să scrie programe grozave Dar atunci când diagnosticați problemele de compatibilitate cu codul pe și de biți pe Windows NT/ și când scrieți utilități de nivel scăzut, este o idee bună să înțelegeți clar semnificația fiecărui bit al mânerului API Win Mânerul de obiect GDI Windows NT/ constă din două componente pe biți, un ID unic și un index în tabelul de obiecte GDI Pentru a obține adresa unui obiect din tabel, este suficient să mascați cei biți inferiori ai manipulatorului, să-i înmulțiți cu și să îi adăugați la adresa de pornire a tabelului de obiecte GDI Adresa de pornire a tabelului de obiecte GDI este stocată în variabilele globale ale bibliotecilor win k sys și gdi dll Am menționat deja un cod unic care oferă protecție suplimentară Codul unic este, de asemenea, inclus în mânerele obiectelor GDI Pentru ca GDI să permită accesarea unui mâner, ID-ul unic al mânerului GDI trebuie să se potrivească cu cel stocat în tabelul de obiecte GDI După obținerea unui index pe tabelul de obiecte GDI, un suplimentar Obiecte GDI, manipulatoare și tabelul de obiecte ID proces de verificare Acest lucru facilitează eliminarea manipulatorilor invalidi, învechiți și deținute din exterior În implementarea actuală, numărul maxim de mânere de obiecte GDI la nivel de sistem (sau la nivel de sesiune pe un Windows Terminal Server) este de Această valoare poate fi crescută cu ușurință la , deoarece doar din cei biți alocați pentru partea de index sunt utilizate în mânerele GDI Aplicațiile utilizator nu ar trebui să se bazeze pe cunoașterea formatului intern al mânerelor GDI sau a structurii tabelului de obiecte GDI, deoarece acestea s-au schimbat în trecut și se pot schimba în versiunile viitoare Pe de altă parte, Windows NT/ pune restricții și protecții suplimentare pentru gestionanții GDI pentru a ajuta la depanarea codului Aveți grijă să nu treceți în afara procesului mânerele GDI și testați aplicațiile pe toate versiunile moderne de Windows Consultați Capitolul pentru mai multe informații despre structurile interne de date GDI API-ul obiectelor GDI Obiectele GDI se încadrează în mai multe categorii Cele mai comune tipuri de obiecte GDI sunt pensule logice, pixuri logice, fonturi logice, palete logice, regiuni, hărți de biți specifice dispozitivului, secțiuni DIB, metafișiere avansate și contexte de dispozitiv Pentru fiecare tip de obiect sunt create funcții speciale pentru a crea obiecte de acest tip Când este creat un obiect, interfața GDI returnează aplicației un handle Multe funcții GDI sunt apelate cu HGDIOBJ, un tip de mâner de obiect GDI generic HGDIOBJ SelectObjectCHDC hDC HGDIOBJ hgdlobj): BOOL DeleteObject(HGDIOBJ hObject): DWORD GetObjectType(HGDIOBJ h); Int GetObject(HGDIOBJ hgdlobj, Int cdBuffer, LPVOID IpvObject); Unele tipuri de obiecte GDI (perii, pixuri, fonturi, palete, hărți de biți specifice dispozitivului și secțiuni DIB) pot fi utilizate ca atribute de context de dispozitiv Astfel de obiecte sunt asociate cu contextul dispozitivului folosind funcția SelectObject Când este apelată, această funcție returnează mânerul obiectului GDI anterior de același tip Pentru a restabili obiectul vechi în contextul dispozitivului, trebuie doar să apelați din nou SelectObject pe valoarea obținută din apelul anterior Paletele logice sunt selectate în contexte de dispozitiv cu funcția specială SelectPalette Când un obiect GDI nu mai este necesar, acesta ar trebui să fie șters cu funcția DeleteObject Înainte de a șterge un obiect, aplicația trebuie să se asigure că nu este selectat în niciun context de dispozitiv Abordările pentru ștergerea obiectelor GDI în Windows / /Me și Windows NT/ sunt ușor diferite Pe Windows / /Me, funcția DeleteObject nu șterge obiectele selectate în contextele dispozitivului, care pot scurge obiecte Pe Windows NT/ , obiectul GDI este șters chiar dacă rămâne selectat Încercările ulterioare de deducere care utilizează obiectul GDI de la distanță au ca rezultat erori, ceea ce face mai ușor pentru programator să diagnosticheze problema Capitol? Pixeli Dacă un program a fost dezvoltat și a funcționat normal pe un computer cu Windows NT/ , dar refuză să funcționeze în Windows / /Me, una dintre posibilele explicații constă în ștergerea incorectă a obiectelor Clasa KGDIObject de mai jos este un simplu wrapper pentru selectarea, excluderea și ștergerea obiectelor GDI clasa KGDIObject { HGDIOBJ m hOld; HDC m hDC: public: HGDIOBJ m hObj; KGDIObject(HDC hDC HGDIOBJ hObj) { m hDC = hDC: m hObj = hObj: m hOld = SelectObject(hDC hObj); assert(m hDC): assert(m hObj); afirmă(m h d): } -KGDIObject" { HGDIOBJ h ■= SelectObject(m hDC m hOld): assert(h==j): DeleteObject(m hObj): // assert(GetObjectType(m hObj)== ): } }; Obiectul KGDIObj conține trei variabile care stochează mânerul obiectului GDI selectat, mânerul contextului dispozitivului și mânerul obiectului sursă în acel context Constructorul selectează un obiect GDI în contextul dispozitivului Cele trei directive assert verifică dacă parametrii sunt corecti și că operația a avut succes Destructorul de clasă elimină obiectul GDI din context și îl îndepărtează Prima directivă assert verifică dacă excepția a trecut normal A doua directivă verifică rezultatul ștergerii obiectului Este comentat în codul de mai sus, deoarece GDI uneori memorează cache obiecte pentru a accelera crearea de obiecte de același tip NOTĂ - - În MFC, wrapper-ul pentru apelarea SelectObject returnează un pointer către o instanță a CGdiObject, clasa de obiecte GDI din MFC Dar dacă MFC nu poate mapa un indicator de obiect GDI la un pointer de obiect MFC, returnează un pointer la un obiect temporar Dacă o aplicație folosește un pointer temporar pentru a exclude un obiect neutilizat din context, se poate întâmpla ca contextul să fi fost deja modificat printr-un alt apel la SelectObject, care va scurge obiecte GDI Obiecte GDI, manipulatoare și tabelul de obiecte Un exemplu simplu de utilizare a clasei KGDIObject: void OnDraw (HDC hDC) { KGDIObject albastru(hDC, CreateSolidBrush(RGB( , ,OxFF)); dreptunghi (hDC, , ); } Când un proces se termină, toate obiectele GDI pe care le-a creat sunt eliminate automat din tabel (probabil prin ID-ul procesului asociat fiecărui obiect GDI) Cu toate acestea, aplicația în sine trebuie să asigure ștergerea corectă a obiectelor, fără a se baza pe sistem pentru a elimina tot gunoiul după finalizarea procesului O scurgere constantă a resurselor GDI perturbă rapid funcționarea normală a întregului sistem Funcția GetObjectType preia un mâner de obiect GDI și returnează un număr întreg care indică tipul obiectului GDI De exemplu, constanta OBJ DC este returnată pentru un context de dispozitiv, constanta OBJ BRUSH pentru un obiect perie logic, constanta OBJ BITMAP pentru un bitmap sau o secțiune DIB specifică dispozitivului și așa mai departe Dacă funcția returnează , atunci obiectul GDI handle-ul transmis acestuia este fie nevalid, fie aparține altui proces Funcția GetObject poate fi folosită pentru a obține informații despre structura sursă transmisă la crearea unor tipuri de obiecte GDI Pentru un bitmap dependent de dispozitiv, completează o structură BITMAP, pentru o secțiune DIB, o structură DIBSECTION, pentru un stilou extins, o structură EXTLOGPEN, pentru un stilou, o structură LOGPEN, pentru o pensulă, o structură LOGBRUSH, pentru un font , o structură LOGFONT, iar pentru o paletă, o structură WORD Apelul către GdiObject primește un mâner de obiect GDI, o dimensiune estimată a structurii și un pointer către un bloc de date suficient de mare pentru a păstra structura Dacă apelantul nu este sigur de câți octeți vor fi necesari pentru a stoca structura, poate obține numărul de octeți apelând funcția GetObject cu un pointer NULL Funcția GetObject vă permite să distingeți între un raster dependent de dispozitiv și o secțiune DIB (funcția GetObjectType nu face distincție între ele) Pentru a face acest lucru, trebuie doar să apelați GetObject cu o structură DIBSECTION; dacă apelul reușește, atunci obiectul GDI este o secțiune DIB Toate tipurile de obiecte GDI vor fi discutate în detaliu după cum este necesar Detectarea scurgerii obiectelor GDI Când apar simptome de scurgeri de obiecte GDI, cum ar fi blocările în timpul redării sau apariția elementelor interfeței sistemului, este foarte dificil să se determine care aplicație cauzează problema, ce resurse sunt irosite și unde se întâmplă Probabil că există un singur program decent pentru detectarea scurgerilor de memorie și resurse - BoundsChecker de la Numega În timpul funcționării sale, BoundsChecker interceptează aproape toate funcțiile API Win pentru salvarea, verificarea și analizarea ulterioară a parametrilor și a valorilor returnate De exemplu, la înregistrarea tuturor apelurilor de funcții API care creează și șterg Capitol? Pixeli Pentru obiecte, un program precum BoundsChecker compară obiectele create cu obiectele eliminate înainte de a termina programul și găsește orice obiect GDI scurs cu informații exacte despre apelant Capitolul descrie unele utilitare pentru urmărirea apelurilor către funcțiile API GDI, funcțiile de sistem și funcțiile DDI Aceste utilitare pot fi ușor îmbunătățite pentru a găsi scurgeri de resurse GDL Cunoscând structurile interne de date ale GDI, puteți scrie cu ușurință un program care monitorizează utilizarea obiectelor GDI de către toate procesele Windows NT/ Un astfel de program va afișa informații despre toate resursele GDI din sistem, deși nu are informațiile necesare pentru a găsi scurgeri Pe fig Figura prezintă fereastra programului GDIObj scrisă special pentru acest capitol Programul scanează în mod regulat conținutul tabelului de obiecte GDI, sortează intrările după ID-ul procesului și tipul, apoi se afișează într-o vizualizare de tabel necunoscut OSA EXE necunoscut services exe necunoscut winlogon exe MSDEV EXE IEXPLORE EXE lsass exe svchostexe spoolsv exe svchostexe MSTask exe Z Explorer exe internatexe tgsched exe zm nt exe d Orez GDI Object Watcher După cum puteți vedea din figură, MS Developer Studio folosește de obiecte GDI, , % din maxim Dacă numărul de mânere GDI utilizate de o aplicație continuă să crească, acesta este un semn sigur al unei scurgeri de obiecte Pentru un proces monitorizat, GDIObj afișează numărul total de obiecte GDI și date individuale pentru mai multe categorii comune Când apare o scurgere, veți ști ce obiecte GDI se pierd Figura arată că primul proces (PID = ) utilizează de obiecte care nu aparțin niciunei categorii Practic, acestea sunt obiecte de font fizic utilizate de GDI În plus, se poate observa din figură că procesele Obiecte GDI, manipulatoare și tabelul de obiecte GUI-urile Win folosesc cel puțin patru obiecte GDI: două contexte de dispozitiv, un bitmap și o perie Aceste obiecte pot fi create în timpul inițializării user dll sau gdi dll Prin urmare, în sistem nu pot funcționa în același timp mai mult de de procese, deoarece tabelul este proiectat pentru doar de manipulatori Windows introduce o nouă caracteristică care permite aplicațiilor să obțină informații despre utilizarea resurselor GDI și USER DWORD GetGulResources(HANDLE hProcess, DWORD uiflags): Funcția GetGulResources raportează câte obiecte GDI sau USER folosește în prezent aplicația Primul parametru al GetGulResources este mânerul procesului care vă interesează Al doilea parametru ia valorile GR GDIOBJECTS și GR USEROBJECTS Funcția returnează numărul curent de obiecte utilizate Funcția GetResources este un mijloc „legitim” pentru a găsi scurgeri de resurse De exemplu, îl puteți apela înainte și după ce un fragment este executat, comparați valorile returnate și vedeți dacă acest fragment creează noi obiecte Deși valori diferite nu sunt întotdeauna indicative pentru o scurgere de resurse din cauza posibilei stocări în cache a obiectelor de către aplicație și GDI, o creștere constantă a numărului de obiecte este un semn sigur al unei scurgeri de obiecte Mai jos este o clasă de wrapper KGUIResource simplă și un exemplu despre cum să o utilizați atunci când procesați un mesaj WM PAINT: clasa KGUIResource { int m gdi mjjser; public: KGUIResourceO { m gdi = GetGuiResources(GetCurrentProcessO, GR GDIOBJECTS); m user = GetGuiResources(GetCurrentProcessO GRJJSEROBJECTS): } ~KGUIResource() { int gdi = GetGuiResources(GetCurrentProcess() GR GDIOBJECTS): int utilizator = GetGuiResources(GetCurrentProcess() GRJJSEROBJECTS): if ( (m gdi==gdi) && (m user==user) ) întoarcere: char temp[ ]: wsprintf(temp "Resource Difference: gdi(£d->£d) user(£d->Xd)\n" m gdi gdi m user user); OutputDebugString(temp): } caz WM PAINT: { KGUIResource res; Capitol? Pixeli PAINTSTRUCT ps; HDC hDC - BeginPaint(m hWnd, &ps): OnDraw(hDC &ps rcPaint): EndPaint(m hWnd, &ps); ) tăiere În grafica computerizată, decuparea este o parte a algoritmului de ieșire grafică care exclude selectiv anumite părți ale unei imagini din procesul de ieșire De exemplu, dacă citiți un document într-un editor de text la mărire mare, doar o mică parte a paginii este afișată în fereastră și totul este tăiat Și dacă includeți un desen într-un cadru oval într-un editor grafic, tot ce se află în afara ovalului este tăiat În mod tradițional, limita este definită în spațiul de adrese logic Să spunem, la ieșire, doar acele primitive grafice care se încadrează în această fereastră sunt afișate într-o fereastră; totul este întrerupt Există algoritmi speciali care calculează intersecția primitivelor grafice cu o fereastră, astfel încât numai zonele nedecupate să fie incluse în ieșire Decuparea este una dintre caracteristicile de bază ale Windows GDI De exemplu, o aplicație poate desena o linie de la origine la un punct pseudo-infinit într-un spațiu de coordonate de de biți (maxint,maxint) Când se atinge limita zonei client a unei ferestre sau a unui context de dispozitiv, redarea se oprește imediat Această abordare simplifică foarte mult proiectarea algoritmilor grafici Tăierea conductei Conceptual, fiecare apel grafic trece prin mai multe niveluri de tăiere, formând o conductă de tăiere Documentația Microsoft despre acest subiect este vagă și uneori nesigură, la fel ca și puținele cărți scrise pe acest subiect Pentru a da un exemplu concret: „Când mânerul de context al dispozitivului este obținut de funcția BeginPaint, DC conține o regiune de tăiere dreptunghiulară predefinită care corespunde unui dreptunghi nevalid care trebuie redesenat” Această descriere conține până la trei erori Următoarele sunt nivelurile de tăiere cunoscute de noi și acceptate de Microsoft Windows Despre fereastra dreptunghiulară Fiecare fereastră are o zonă dreptunghiulară, care este definită inițial la apelarea CreateWindow/CreateWindowEx și poate fi modificată ulterior Orice lucru din afara dreptunghiului ferestrei este tăiat tăiere Despre fereastra Regiune O aplicație poate schimba regiunea unei ferestre și poate da ferestrei o formă arbitrară folosind funcția SetWindowRgn Orice lucru din afara regiunii ferestrei este tăiat Oh Vizibilitate Ferestrele se pot suprapune între ele; O fereastră poate avea ferestre pentru copii sau vecine Orice parte a unei ferestre care este acoperită de o altă fereastră este tăiată Zonele ascunse de copii și ferestrele adiacente pot fi, de asemenea, tăiate folosind steagurile WS CLIPCHILDREN și WS CLIPSIBLINGS Despre zona client Dacă contextul dispozitivului se potrivește cu zona client a ferestrei, orice lucru din afara zonei client este trunchiat Despre Regiunea actualizată Win acceptă un API pentru a determina regiunea de actualizare a ferestrei, regiunea care trebuie actualizată Descrierea regiunii actualizate poate fi obținută folosind funcția GetUpdate-Region Pentru contextul dispozitivului returnat de funcția BeginPaint, orice lucru din afara regiunii care este actualizată este trunchiat Despre regiunea de sistem O regiune combinată construită ținând cont de factorii enumerați mai sus se numește regiune de sistem Informațiile despre regiunea de sistem a contextului dispozitivului pot fi obținute folosind funcția GetRandomRgn(hDC, hRgn, SYSRGN) Despre Metaregion Regiunea meta formează primul nivel de tăiere în contextul dispozitivului sub controlul aplicației Orice în afara metaregiunii este trunchiat O Regiunea de tăiere Regiunea de clipare (regiunea de clipare) formează al doilea nivel de tăiere în contextul dispozitivului aflat sub controlul aplicației Orice în afara acestei regiuni este întrerupt Acum să reformulam descrierea regiunii de tăiere de mai sus, care menționează funcția BeginPaint Când un handle de context al dispozitivului este obținut de către BeginPaint, DC conține o regiune de sistem predefinită, care poate fi sau nu dreptunghiulară; este generat pe baza regiunii ferestrei care se actualizează, ținând cont de alți factori Metaregiunea și regiunea de tăiere încep întotdeauna cu starea regiunilor NULL; ele permit aplicaţiei să controleze procesul de tăiere Regiunea sistemului este gestionată de sistemul de operare și este actualizată automat când fereastra este redimensionată sau mutată Metaregiunea și regiunea de tăiere sunt sub controlul aplicației Un pixel este afișat numai dacă aparține intersecției regiunii de sistem, a metaregiunii și a regiunii de tăiere Într-un sens, termenul „decupare” din numele „regiune de tăiere” este confuz, deoarece această regiune definește punctele rămase, nu punctele de tăiere Numai ceea ce este în afara acestei regiuni este tăiat Regiuni simple O regiune este un set de puncte dintr-un spațiu de coordonate Acest set poate fi gol sau poate consta din puncte care formează un dreptunghi, un cerc sau o formă arbitrară sau ocupă întreaga coordonată Capitol? Pixeli suprafata solului Win oferă un set bogat de funcții API pentru a trata regiunile ca un tip de obiect GDL Această secțiune acoperă câteva caracteristici simple care ne vor pune în practică, iar materiale mai avansate vor fi tratate în capitolele următoare În Win , o regiune este același obiect gestionat de GDI ca și contextul dispozitivului, creionul logic, pensula logică și așa mai departe Când o aplicație apelează funcția de creare a regiunii, sistemul creează un obiect regiune, îl inițializează cu datele dorite, și returnează aplicației un handle de regiune Detaliul de regiune (tip HRGN) este transmis ulterior la GDI atunci când se efectuează operațiuni de regiune Cel mai simplu mod de a crea o regiune este: HRGN CreateRectRgn( int hLeftRect Int nTopRect Int nRightRect int nBottomRect); Funcția creează o regiune dreptunghiulară care conține toate punctele dreptunghiului definite de vârfuri (nLeftRect, nTopRect) și (nRightRect, nBottomRect), cu excepția marginilor de jos și din dreapta Rețineți că pozițiile relative ale vârfurilor nu sunt fixe; GDI aranjează automat punctele astfel încât să formeze un dreptunghi Să ne uităm la câteva exemple: HRGN hRgnl = CreateRectRgn(O, ): HRGN hRgnl = CreateRectRgn(O ); HRGN hRgnl = CreateRectRgn(- x FFFFFF - x FFFFFF - x FFFFFF - x FFFFFF); HRGN hRgnl = CreateRectRgnd ); Prima regiune este goală, iar a doua conține doar un punct ( , ) Al treilea apel creează probabil cea mai mare regiune susținută de implementarea GDI pe de biți în Windows NT/ Ultima regiune este identică cu a doua Excluderea marginilor drepte și inferioare duce adesea la neînțelegeri Când se creează o regiune dreptunghiulară { , , , }, GDI salvează un obiect regiune cu un dreptunghi { , , , } în loc de { , , , } Marginile din dreapta și de jos sunt excluse doar în etapa finală a ieșirii sau procesării unor solicitări de informații Această abordare simplifică operațiunile cu regiuni De exemplu, dacă regiunea { , , , } este mărită de n ori, aceasta devine regiunea { , , n, n} care conține n x n puncte Și cum să scalați regiunea reprezentată de cvartetul { , , , }? Ar trebui să se transforme în {O, O, O, } sau în { , , n- , n- }? Când un obiect regiune nu mai este necesar, eliberați resursele asociate cu acesta cu funcția DeleteObject Regiunea decupată Unul dintre atributele unui context de dispozitiv este regiunea de tăiere Acest atribut stochează un obiect regiune definit de aplicație care descrie limitele regiunii în care este efectuată ieșirea Pentru contextele de dispozitiv returnate de BeginPaint, GetDC sau CreateDC, regiunea clipului este goală (atributul este NIILL) În acest caz, se spune că aplicația nu are regiune de tăiere Regiunea de tăiere NULL nu trebuie confundată cu regiunea goală în sensul teoriei mulțimilor; dimpotrivă, este complet opusul său Cu o regiune goală tăiere nicio tăiere (de exemplu, CreateRectRgnCO, , , )) nu este afișat nimic, adică întreaga imagine este tăiată Regiunea de tăiere NULL înseamnă că totul din regiunea de sistem este afișat Astfel, o regiune clipă goală este un set gol de puncte, iar o regiune NULL poate fi gândită ca un set complet de puncte de pe suprafața dispozitivului (în acest caz, se vorbește și despre absența unei regiuni de clip în contextul dispozitivului) ) Funcțiile de bază pentru lucrul cu regiunile de tăiere sunt enumerate mai jos Int GetCl pRgn(HDC hDC, HRGN hrgn); int SelecteiipRgn(HDC hDC HRGN hrgn); int ExtSelectClipRgn(HDC hDC HRGN hrgn int fnMode); int OffsetC pRgn(HDC hDC int nXOffset int nYOffset); int ExcludeClipRect(HDC hDC int nLeftRect, int nTopRect, int nRightRect int nBottomRect); int IntersectClipRect(HDC hDC, int nLeftRect int nTopRect, int nRightRect, int nBottomRect); int GetClipBox(HDC hDC, LPRECT Iprc); Multe funcții de regiune a clipurilor returnează un cod de complexitate a regiunii întregi Alte funcții (cum ar fi GetClipRgn) returnează un cod de ieșire ( , sau - ) Unele dintre codurile de dificultate permise sunt enumerate mai jos NULLREGION O regiune goală (fără puncte) SIMPLERGION O regiune constă dintr-un singur dreptunghi COMPLEXREGION O regiune are o structură mai complexă EROARE A apărut o eroare (starea anterioară a regiunii nu se modifică) Codul NULLREGION înseamnă că regiunea este goală (de exemplu, a fost obținută ca urmare a intersecției a două regiuni neadiacente) După cum sa menționat mai sus, o regiune goală nu trebuie confundată cu o regiune NULL Codul SIMPLEREGION înseamnă că setul de puncte din regiune formează un dreptunghi Codul COMPLEXREGION descrie orice regiune validă care nu poate fi reprezentată printr-un dreptunghi simplu Codul de EROARE înseamnă de obicei că au fost transmise valori invalide sau NULL în apelul funcției GDI Dacă știți cum să interacționați cu contextele dispozitivului altor obiecte GDI (cum ar fi pixuri, pensule sau fonturi), API-ul Clip Regions poate părea ciudat și de neînțeles Funcția GetCurrentObject returnează informații despre stiloul, pensula sau fontul curent selectat în contextul dispozitivului, iar funcția SelectObject le înlocuiește cu un nou obiect GDI Un obiect selectat într-un context de dispozitiv este considerat în uz și poate fi șters numai după ce a fost eliminat din context Interacțiunea obiectului regiune cu contextul dispozitivului se bazează mai mult pe datele care definesc regiunea decât pe mânerul regiunii Mai precis, un context de dispozitiv nu poate obține mânerul regiunii de tăiere curente și, odată ce o regiune de decupare este selectată într-un context de dispozitiv, mânerul său nu mai este considerat utilizabil în acel context Pentru a obține regiunea de tăiere curentă pentru un context de dispozitiv, o aplicație trebuie să creeze un obiect regiune valid și să-și transmită mânerul la funcția GetClipRgn din parametrul hrgn Astfel, hrgn se referă la un obiect de regiune valid, deși nu este utilizat cu adevărat Dacă Capitol? Pixeli contextul dispozitivului conține regiunea de tăiere, GetCl ipRgn eliberează obiectul regiune referit de hrgn, creează o copie a regiunii de tăiere din contextul dispozitivului și plasează o referință la noua regiune de tăiere în hrgn Rezultatul returnat de GetClipRgn este codul de dificultate al regiunii (regiune goală, dreptunghiulară sau complexă) Dacă nu este specificată nicio regiune de tăiere în contextul dispozitivului, valoarea (EROARE) este returnată și parametrul hrgn nu este modificat Când apelați SelecteiipRgn, mânerul unui obiect de regiune valid poate fi transmis în parametrul hrgn În acest caz, GDI creează o copie a datelor regiunii și o asociază cu contextul dispozitivului Rețineți că manipulatorul trecut nu este atribuit unui context de dispozitiv; aplicația o poate șterge după apel Parametrul hrgn poate fi, de asemenea, NULL; în acest caz, obiectul clip-region stocat în contextul dispozitivului este eliberat, iar clip-region este setată la NULL în contextul dispozitivului Atributele contextului, cum ar fi stiloul logic, sunt, într-un anumit sens, stabilite de manipulatorii lor Odată ce un mâner de obiect este selectat într-un context de dispozitiv, acesta este considerat utilizat în acel context și nu poate fi eliminat până când un alt mâner de obiect de același tip este selectat în context Pe de altă parte, regiunea de tăiere este setată de datele sale Trecerea unui handle de regiune la funcția SelecteiipRgn creează o copie a datelor de regiune, nu de identificare a regiunii Când o aplicație dorește să obțină regiunea de tăiere curentă, oferă un handle de regiune valid și datele regiunii respective sunt înlocuite cu datele regiunii de tăiere Dacă nu există nicio regiune de tăiere în contextul dispozitivului, funcția GetCl ipRgn returnează , caz în care parametrul regiune nu este modificat În general, contextele de dispozitiv nou create returnate de BeginPaint sau CreateDC nu au o regiune de clip, așa că GetClipRgn returnează întotdeauna Din nou, nicio regiune de clip înseamnă că este afișat întregul conținut al regiunii de sistem O aplicație ar trebui să verifice întotdeauna rezultatul unui apel la GetClipRgn și să acționeze în funcție de situație, mai degrabă decât să se bazeze doar pe manipulatorul obiectului regiune De exemplu, următorul fragment verifică dacă funcția GetClipRgn a returnat valoarea ; în acest caz, elimină obiectul regiune și își setează mânerul la NULL Acest handle, care este NULL, poate fi folosit de aplicație pentru a determina dacă o regiune de tăiere este prezentă în contextul dispozitivului HRGN hRgn = CreateRectRgn(O ): dacă ( GetCl pRgn(hDC, hRgn)==O) { DeleteObject(hRgn); hRgn - NULL; } După cum am menționat mai sus, o regiune este un set de puncte Prin urmare, operațiunile pe regiuni sunt ușor de modelat pe baza operațiilor pe seturi În tabel Tabelul rezumă operațiunile suportate de GDI tăiere Tabelul Operații binare cu regiuni Mod Rezultat RGN AND Regiunea corespunzătoare regiunii și regiunii se suprapun RGNCOPY Copie a regiunii Regiunea RGNJHFF ale cărei puncte aparțin regiunii , dar nu aparțin regiunii Regiunea RGNOR ale cărei puncte aparțin cel puțin uneia dintre regiunile și RGN XOR Regiunea ale cărei puncte aparțin fie regiunii , fie regiunii , dar nu ambelor Când un obiect regiune este selectat ca regiune de tăiere sau metaregiune într-un context de dispozitiv, se presupune că este definit în sistemul de coordonate al dispozitivului din acel context În acest sens, funcțiile regiunilor diferă de funcțiile GDI, cărora li se transmit de obicei coordonatele logice ale contextului dispozitivului Puteți utiliza funcția LPtoDP GDI pentru a converti coordonatele din sistemul logic în sistemul de coordonate al dispozitivului De asemenea, ar trebui să fii bun la regiunile goale și absolute Regiunea goală nu conține niciun punct, așa că funcția CreateRectRgnCO ( , , ) creează o regiune goală O regiune absolută conține toate punctele din spațiul de coordonate Cu toate acestea, o încercare de a transmite numere minime și maxime de de biți funcției CreateRectRgn eșuează Se pare că regiunea de dimensiune maximă este creată cu următoarele opțiuni: {- x FFFFFF, - x FFFFFF x FFFFFF, x FFFFFF} Acest lucru este fără îndoială deoarece motorul grafic utilizează numere în virgulă fixă în format în sistemul de coordonate al dispozitivului, care conține o parte întreagă cu semn de de biți Cu toate acestea, în scopuri practice, este posibil să se genereze o regiune „absolută” pe baza dimensiunilor suprafeței dispozitivului fizic în pixeli Funcția ExtSelectCHpRegion vă permite să controlați mai bine procesul de combinare a regiunii hrgn cu o regiune de tăiere existentă în contextul dispozitivului pentru a obține o nouă regiune de tăiere folosind operațiunile enumerate în Tabelul În acest caz, primul operand este regiunea de tăiere curentă a contextului dispozitivului, iar al doilea operand este specificat de parametrul hrgn Pentru funcția ExtSelectCHpRegion, modul RGN COPY atribuie o copie a hrgn ca regiune de tăiere curentă, ca și pentru funcția SelecteiipRegion După cum sa menționat mai sus, contextele de dispozitiv nou create returnate de BeginPaint și GetDC nu au o regiune de tăiere; cum funcționează funcția ExtSelectClipRegion în acest caz? Când apelați ExtSelectClipRegion pentru contexte de dispozitiv fără o regiune de clip, RGN AND este interpretat ca RGN COPY Pentru RGN DIFF, RGN OR sau RGN XOR, se utilizează dimensiunea dispozitivului fizic Luați în considerare următorul fragment: PAINTSTRUCT ps: HDC hDC = BeginPa nt(hWnd & ps); Capitol? Pixeli HRGN hRgn = CreateRectRgnCO, , ): Int rslt = ExtSelectCl p(hDC, hRgn, RGN DIFF): rslt = GetCl pRgn(hDC, hRgn); Acest fragment creează o regiune dreptunghiulară de x și încearcă să schimbe regiunea de tăiere curentă cu o operație RGN DIFF Nu există nicio regiune de tăiere în contextul dispozitivului, așa că în modul ecran x motorul grafic utilizează regiunea dreptunghiulară { , , , } și funcția GetClipRgn returnează o regiune formată din două dreptunghiuri { , , , } și { } Următoarele trei funcții pentru lucrul cu regiunile de tăiere sunt simple Pentru un context de dispozitiv care are o regiune de tăiere, funcția OffsetClipRgn compensează toate punctele obiectului cu (nXOffset, nYOffset) Funcția Exclude- ipRgn elimină un dreptunghi din regiunea curentă de tăiere, similar modului RGNJHFF al funcției ExtSelectClіp Funcția IntersectClipRect calculează intersecția regiunii curente de tăiere cu un dreptunghi, similar modului RGN AND al funcției ExtSelectClіp În comparație cu ExtSelectClir, funcțiile ExcludeClipRect și IntersectClipRect oferă o modalitate mai ușoară de a modifica regiunea de tăiere Funcția GetCl ipBox returnează cea mai mică casetă de delimitare la intersecția dintre regiunea curentă a sistemului și regiunea de tăiere Atenție: vorbim de intersecția acestor două regiuni! În mod implicit, nu există nicio regiune de tăiere în contextul dispozitivului, așa că GetClіpBox returnează dreptunghiul de delimitare al regiunii de sistem care se potrivește cu dreptunghiul rcPaint din structura PAINTSTRUCT completată de funcția BeginPaint Deoarece regiunea de tăiere este construită prin apeluri către SelecteiipRgn și ExtSelectClipRgn, motorul GDI ține evidența intersecției cu regiunea de sistem și caseta de delimitare, care este returnată de funcția GetClipIn Dacă aplicația modifică regiunea de tăiere în timp ce procesează mesajul WM PAINT, apelul GetClipBox oferă informații mai precise decât dreptunghiul rcPaint Metaregiune Metaregiunile sunt printre caracteristicile în mare parte nedocumentate ale GDI Ele nu sunt menționate printre atributele contextului dispozitivului, nu li se dă o valoare implicită și relația lor cu regiunea sistemului și regiunea de tăiere nu este explicată Materialul suplimentar se bazează pe cercetările proprii ale autorului O meta-regiune este o „regiune de tăiere de prim nivel” care controlează decuparea la un alt nivel Amintiți-vă principiul decupării în GDI: într-un context de dispozitiv, ieșirea este limitată la intersecția regiunii sistemului, a metaregiunii și a regiunii de tăiere Tot ce se află în afara acestei zone este tăiat Dacă vi se pare prea incomod să lucrați cu un nivel de tăiere la nivelul aplicației, aveți la dispoziție un al doilea nivel (similar celor două niveluri ale sistemelor de coordonate logice GDI) Dacă un nivel de cutoff, definit de aplicație, este suficient pentru dvs , puteți uita de metaregiuni tăiere Contextul dispozitivului nou creat nu are o metaregiune Chiar și după selectarea unei regiuni de tăiere, metaregiunea încă nu există până când este apelată funcția SetMetaRgn Funcțiile API pentru lucrul cu metaregiuni sunt enumerate mai jos int SetMetaRgn(HDC hDC): int GetMetaRgn(HDC hDC, HRGN hRgn): Spre deosebire de alte funcții cu prefixul Set, funcția SetMetaRgn preia un singur parametru, mânerul contextului dispozitivului Un alt parametru implicit este regiunea de tăiere curentă Funcția SetMetaRgn înlocuiește metaregiunea curentă și intersecția acesteia cu regiunea de tăiere curentă, apoi resetează contextul dispozitivului la o stare în care nu are o regiune de tăiere Deoarece metaregiunea decupează primitivele grafice în același mod ca o regiune de tăiere, decuparea generală în contextul dispozitivului nu este schimbată imediat după apelarea SetMetaRgn Dar acum că aplicația a mutat vechea regiune de tăiere la nivelul meta-regiune, poate construi o nouă regiune de tăiere care va oferi restricții suplimentare asupra ieșirii Funcția GetMetaRgn funcționează destul de bine; acesta (prin analogie cu GetClipRgn) returnează datele meta-regiunii curente prin manipulatorul regiunii existente Contextul dispozitivului nou creat nu are o regiune de clip, așa că GetMetaRgn returnează în acest caz fără a actualiza hRgn Este interesant de observat că atunci când se apelează SetMetaRgn de mai multe ori, metaregiunea contextului scade și nu crește niciodată în dimensiune, iar după definiție, metaregiunea nu mai poate fi resetată la starea regiunii NULL O soluție este să utilizați funcțiile SaveDC și RestoreDC Luați în considerare un exemplu de utilizare a unei metaregiuni Următorul fragment creează o metaregiune de x și o regiune de tăiere, dar cu un offset de x , astfel încât toată ieșirea este limitată la o regiune de x HRGN hRgn = CreateRectRgn(O, , , ); Selectei pRgn(hDC, hRgn); // Meta: niciunul, regiune de tăiere: x SetMetaRgn(hDC): // Meta: x , regiune de tăiere: nu Selectei pRgn(hDC, hRgn): // Meta: x , Regiunea clip: Același OffsetCl pRgn(hDC, ): // Meta: x regiune de tăiere: x dreptunghi ( , , , ); // Desenează un dreptunghi de x DeleteObject(hRgn): Probabil v-ați dat seama până acum că meta-regiunile nu sunt o caracteristică necesară Dacă o aplicație gestionează toată tăierea la un nivel, poate simula cu ușurință metaregiuni și chiar mai complexe Dar dacă aplicația dvs folosește o schemă de ieșire stratificată, atunci metaregiunea vă permite să controlați tăierea în două locuri Să presupunem că o aplicație redă ieșirea folosind un DLL terță parte, iar codul de ieșire folosește o regiune de clip GDI O aplicație nu va putea modifica codul sursă al altcuiva pentru a limita ieșirea la o anumită regiune, dar poate seta o metaregiune și poate obține același efect Existența unor caracteristici puțin cunoscute ale API-ului Win , care includ metaregiuni, este întotdeauna explicată din motive practice Metaregiunile sunt folosite de GDI atunci când redă metafișiere Capitolul Pixeli Cinci regiuni de context de dispozitiv Deci, avem o regiune de sistem, o meta-regiune și o regiune de tăiere în contextul dispozitivului Intersecția lor determină de fapt zona în care are loc ieșirea Regiunea sistemului este sub controlul managerului de ferestre; metaregiunea și regiunea de tăiere sunt controlate de aplicația utilizator Dacă pentru fiecare apel grafic GDI ar trebui să recalculăm intersecția și să o transmitem driverului de dispozitiv, motorul grafic ar fi extrem de ineficient După cum este ușor de ghicit, contextul dispozitivului conține încă două regiuni care măresc viteza de ieșire: regiunea API și regiunea Pao Regiunea API este intersecția meta-regiunii cu regiunea cut-off Desigur, numele se datorează faptului că această regiune se află sub controlul GDI API Regiunea Rao este intersecția regiunii API cu regiunea sistemului A fost numit după programatorul Microsoft care a sugerat stocarea acestei regiuni în contextul dispozitivului La schimbarea meta-regiunii sau a regiunii de delimitare, sistemul recalculează regiunea API și regiunea Pao Regiunile sunt stocate în contextul dispozitivului ca pointeri către obiectele nucleului, nu ca mânere Devine clar de ce funcția SetCl i pRgn creează o copie a regiunii în loc să folosească manipulatorul GDI, iar manipulatorul real de regiune ar trebui să fie transmis ca parametru funcției GetCl pRgn Dintre aceste cinci regiuni, datele privind regiunea de sistem, metaregiune, regiunea de tăiere și regiunea API pot fi preluate apelând o singură funcție API GetRandomRgn Te-ai întrebat vreodată de ce această funcție se numește GetRan-domRgn ? Ce beneficii poate aduce o regiune aleatorie? Funcția GetRandomRgn oferă acces aleatoriu la patru regiuni stocate în contextul dispozitivului Ultimul parametru pentru GetRandomRgn este un index întreg pentru care este documentată o singură valoare SYSRGN ( ) Alte valori acceptabile: #define CLIPRGN // GetCl pRgn #define METARGN // GetMetaRgn #define APIRGN #define SYSRGN Cu ajutorul funcției GetRandomRgn, aplicația poate obține date despre regiunea de tăiere, metaregiunea, regiunea API și regiunea sistemului Regiunea Pao este ușor de calculat din datele regiunii API și ale regiunii sistemului Reprezentarea vizuală a regiunilor în contextul dispozitivului În secțiunea „Exemplu de program: Plotarea în contextul dispozitivului” din Capitolul , am creat un program pentru a vizualiza mesajele de pictură ale ferestrelor și ale regiunii sistemului Dacă credeți că astfel de programe Adică „Obțineți o regiune arbitrară”, dar este posibilă o altă traducere - „obțineți o regiune aleatorie” - Notă transl tăiere Deoarece suntem scrisi „pentru manechin” și nu suntem potriviti pentru profesioniști, în această secțiune vom scrie un nou program ClipRegion care oferă o reprezentare vizuală a regiunii de tăiere, a metaregiunii și a regiunii API împreună cu regiunea sistemului În primul rând, avem nevoie de o funcție pentru a obține toate cele patru regiuni și pentru a afișa informații despre ele într-o casetă de text Funcția DumpRegions este dată mai jos void KMyCanvas::DumpRegions(HDC hDC) { pentru (int - : mx ) { mx = albastru: major = Albastru: } dacă (mn==mx) Culoare luminozitate = mn/ : saturație = : nuanță = O; } el se { Luminozitate = (mn+mx) / : dacă (luminozitate = ) nuanță = nuanță - : } } unsigned char Valoare (dublu ml, dublu m , dublu h) { dacă (h >= ) h -= : altfel dacă (h R XORPEN R NOTMASKPEN ІngіIMNі R MASKPEN Ml R -NOTXORPEN Ol r nop R MERGENOTPEN MIGIRVM R COPYPEN CVIIII MS R MERGEPENNOT | ■■ R MERGEPEN l-ws"' ІІійЖ' R ALB » ml Orez Efectul operațiunilor raster binare (modul True Color) Când utilizați operații raster binare, rețineți că operațiunile sunt definite pentru culorile fizice, nu pentru valorile logice COLORREF Astfel, rezultatul operațiunilor este mai mult sau mai puțin dependent de dispozitiv Pentru dispozitivele care folosesc spațiul de culoare RGB, operațiunile sunt aplicate fiecăreia dintre cele trei componente RGB, astfel încât rezultatul este destul de previzibil, dar nu întotdeauna justificat logic Modelul de culoare RGB stochează valorile de intensitate ale culorilor primare, astfel încât utilizarea operațiilor logice pe biți nu găsește întotdeauna o potrivire în percepția culorilor Pentru dispozitivele cu paletă, operațiunile bitmap sunt aplicate indicilor de culoare, astfel încât rezultatul depinde de ordonarea culorilor în paletă În sistemele de operare multitasking din familia Windows, aplicațiile nu au control total asupra paletei hardware a sistemului GDI are Operații raster binare funcții speciale, cu ajutorul cărora aplicația efectuează modificări în paleta sistemului, iar ferestrele din prim plan au drept de prioritate Prin procesarea mesajelor speciale, aplicația poate răspunde la modificările din paleta sistemului Paletele sunt tratate în detaliu în Capitolul Operațiile raster binare joacă un rol important în grafica computerizată Modul R BLACK este folosit pentru a umple pixeli în negru ( ), în timp ce modul R WHITE este folosit pentru a picta pixeli în alb ( sau xFFFFFF într-un framebuffer de de biți) Modul R N TC PYPEN inversează culoarea stiloului Modul R N P suprimă complet ieșirea liniilor și curbelor - acest lucru este foarte convenabil dacă nu doriți să desenați un chenar în jurul dreptunghiului Modul R MASKPEN asigură suprimarea selectivă a biților de pe suprafața grafică a contextului dispozitivului De exemplu, dacă modul R MASKPEN este utilizat pentru un creion RGB(OxFF OO) într-un framebuffer RGB, datele canalului albastru și verde sunt mascate atunci când liniile sunt ieșite, lăsând doar datele canalului roșu Când utilizați RGB( x F, x F, x F), culorile strălucitoare sunt suprimate, deoarece după ieșire, intensitatea maximă a fiecărui canal va fi doar în loc de Modurile R N T și R X RPEN sunt adesea folosite în grafica interactivă pe computer pentru a afișa punctele de vedere și contururile elastice Crosshair-ul este format din linii orizontale și verticale pe întregul ecran Punctul de intersecție al acestor linii determină poziția curentă a cursorului Crosshairs sunt adesea folosite la alinierea obiectelor în editorii grafici Contururile elastice se schimbă dinamic și reprezintă anumite limite definite de utilizator folosind mouse-ul sau tastatura Dreptunghiurile elastice și alte forme sunt adesea folosite în construcția și selectarea formelor geometrice în pachetele grafice În procesul de mișcare a mouse-ului, construcția figurii este considerată a fi încă neterminată, prin urmare, este imposibil să remediați figura În schimb, atunci când utilizatorul mută mouse-ul, aplicația trebuie să deseneze rapid calea, să o ștergă, să restabilească conținutul original și să-l mute într-o nouă poziție Operațiile binare R N T, R X RPEN și R N TX RPEN vă permit să desenați rapid linii temporare și să le ștergeți fără a lăsa urme, deoarece atunci când aplicați din nou aceste operațiuni, conținutul original este restaurat - una dintre proprietățile operațiilor logice Lista arată cum să implementați un reticulat folosind operația R N T Clasa ferestre stochează ultima poziție a cursorului în variabile (m lastx,m lasty) Pentru fiecare mesaj WM MOUSEMOVE, funcția de ieșire în cruce este apelată de două ori - pentru a elimina liniile vechi și pentru a desena linii noi Lista - Ieșire Crosshair folosind R NOT void KMyCanvas::DrawCrossHair(HDC hDC bool activat) { dacă ( m lastx , folosit la trasarea zonelor închise pene Una dintre componentele stilului stiloului este regula alternării segmentelor și golurilor în linia desenată Pixurile cu stilurile PS SOLID și PS INSIDEFRAME desenează linii solide, în timp ce stiloul PS NULL nu desenează deloc, așa că mai sunt stiluri de rezolvat Stiloul PS DASH punctat este format din linii lungi de pixeli separate de pixeli Creionul cu puncte PS DOT constă din linii de pixeli separate prin spații de pixeli Pixul cu puncte PS DASHDOT este construit conform regulii „segment pixeli, gap pixeli, segment pixeli, gap pixeli” Pixurile PS DASHDOTDOT folosesc un ciclu de pixeli, pixeli, pixeli, pixeli, pixeli, pixeli Probabil, Microsoft a decis că un pixel este prea mic, așa că un punct de pe linie este reprezentat de trei pixeli Pe fig Figura prezintă ciclurile de rotație a pixelilor în stilurile enumerate în Tabelul Coloana din stânga arată numele stilului, cea din mijloc arată un exemplu de linie trasată cu stiloul acelui stil, iar aceeași linie este afișată mărită în dreapta Liniile din figură sunt desenate în modul de umplere OPAC cu un stilou întunecat pe un fundal deschis După cum puteți vedea din figură, stiloul PS NULL nu scoate nimic, nici măcar pixeli de fundal Dacă grosimea liniei este de un pixel în sistemul de coordonate al dispozitivului, stiloul PS INSIDEFRAME este echivalent cu PS SOLID În liniile altor stiluri, ciclul de alternare a pixelilor este clar vizibil PSOLID ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ PS DASH ■■■■■■■■■■■■■■■■■MSHMMMMMM PS DOT PS-DASHDOT -■■■■■■■■■MMWMMSHPSHSHMMMM PS DASHDOTDOT PSNULL PSJNSIDEFRAME - ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Orez Stiluri simple de stilouri Al doilea parametru al CreatePen specifică lățimea liniei într-un sistem de coordonate logic Grosimea reală a liniei în coordonate fizice depinde de transformările lumii și de modul în care fereastra este mapată în fereastra De exemplu, în modul MM LOENGLISH cu aceeași transformare a lumii, un stilou cu o lățime logică de desenează întotdeauna o linie care este aproape de , inchi grosime pe imprimantă, indiferent de rezoluție O zecime de inch corespunde la de pixeli pe o imprimantă de dpi sau de pixeli pe o imprimantă de dpi Un stilou cu grosimea este interpretat într-un mod special; desenează întotdeauna o linie groasă de pixel în coordonate fizice Dacă grosimea fizică a unui stilou este mai mare de pixel, atunci creionul creat de funcția CreatePen nu desenează linii de stil complet, cum ar fi linii întrerupte și punctate În schimb, sunt desenate doar linii uniforme cu grosime mai mare Cu alte cuvinte, stiloul logic creat de funcția CreatePen poate desena linii de stil doar cu o grosime de un pixel Creșterea grosimii pixurilor face ca liniile trasate să pară mai complexe Fiecare linie este definită de axa de bază Să presupunem că arde Capitolul linia umbrelă este definită de două puncte ( , ) și ( , ) Dacă lățimea liniei este de un pixel, este destul de evident că punctele ( ), ( ) și așa mai departe până la ( ) ar trebui incluse în linie Dar dacă lățimea liniei este de pixeli, acea linie poate fi desenată în mai multe moduri diferite Prima întrebare este cum ar trebui să fie poziționați pixelii liniei în raport cu axa de bază? Pentru toate stilourile, cu excepția stilourilor PS INSIDEFRAME, linia trasată este centrată în jurul axei sale de bază Pixurile cu stilul PS INSIDEFRAME sunt folosite atunci când mângâiați anumite forme GDI (dreptunghiuri simple și rotunjite, elipse și așa mai departe) În acest caz, centrul liniei este deplasat în interiorul zonei, astfel încât linia să nu depășească limitele conturului Pentru a desena o linie în interiorul unei căi, GDI trebuie să știe exact care dintre cele două laturi ale liniei este interiorul și care este exteriorul Prin urmare, atunci când desenați linii regulate și chiar poligoane, stiloul PS INSIDEFRAME desenează o linie solidă obișnuită centrată pe axa de bază, deoarece GDI nu știe ce latură este interiorul Stilul PS INSIDEFRAME este activat numai atunci când anumite forme sunt desenate cu un interior și exterior clar distins Nu orice linie poate fi centrată cu precizie pe axa de bază Numai în linii verticale și orizontale cu lățimi impare, un pixel este în centru, iar restul sunt distribuite uniform pe ambele părți ale acestuia Când desenați linii mai groase, apare o altă întrebare - cum ar trebui să arate capetele liniilor? Pentru pixurile create cu funcția CreatePen, liniile se termină întotdeauna în capete semicirculare Pe fig Figura arată capetele liniilor de stil PS DOT desenate cu diferite grosimi ale stiloului creat de funcția CreatePen Dacă grosimea fizică este sau , atunci linia trasată este într-adevăr punctată Cu o creștere a grosimii liniei de ambele părți ale axei de bază (lumină pene puncte), apar pixeli suplimentari (puncte întunecate), formând linii mai groase și capete rotunjite Vă rugăm să rețineți: numai cu o grosime impară, linia este centrată simetric față de axa de bază NOTĂ - - În Windows / , liniile groase sunt desenate diferit decât în figura obținută în Windows Pixelii nu sunt distribuiti uniform pe cele două laturi ale axei de bază, iar completarea nu are forma normală semicirculară Pene extinse Odată ce înțelegeți toate limitările, devine clar că pixurile simple create cu funcțiile CreatePen sau CreatePenIndirect există doar în două forme: un stilou cu o grosime de un pixel și un stilou mai gros cu vârf rotund Stilul PS INSIDEFRAME, datorită implementării sale în Windows GDI, nu este deosebit de util, deoarece poate fi aplicat doar unor forme înscrise într-un dreptunghi Cu toate acestea, pentru aceste forme, aplicația poate obține cu ușurință același efect cu un stilou obișnuit, făcând caseta de delimitare puțin mai mică Pentru a depăși aceste limitări, API-ul Win a introdus o nouă funcție ExtCreatePen care creează stilouri extinse cu un set bogat de atribute HPEN ExtCreatePen(DWORD dwPenStyle, DWORD dwWidth, CONST LOGBRUSH * Iplb DWORD dwStyleCont CONST DWORD * IpStyle); Funcția ExtCreatePen vă permite să creați pixuri cu tipuri, stiluri, tipuri de terminații și tipuri de conexiuni Toate aceste informații sunt definite de un parametru dwStyle ca o combinație de steaguri din Table , combinat de operatorul SAU pe biți (|) Tabelul Tipuri, stiluri, finisaje și conexiuni ale stilourilor extinse Restricții pentru semnificația steagului Tipuri PSCOSMETIC Pix cosmetic Grosimea este de un pixel PS GEOMETRIC Pix geometric Grosimea stiloului este specificată în unități logice Stiluri PSSOLID Linie continuă, toți pixelii sunt desenați Alinierea la centru PS DASH Linie punctată Alinierea nu este acceptată în Windows / pene geometrice centrate cu acest stil Continuare Capitolul Tabelul Continuare Restricții pentru semnificația steagului PS DOT Linie punctată Alinierea la centru PS DASHDOT Linie punctată întreruptă Alinierea la centru PS DASHDOTDOT Segment de linie și două puncte Alinierea la centru PS-NULL Nu este trasată nicio linie PSJNSIDEFRAME Linie continuă, toți pixelii sunt desenați Aliniere în interiorul căii Numai pixuri geometrice, utilizate numai la trasarea unor forme GDI PSJJSERSTYLE Alternanța liniilor și a golurilor este setată de parametrii dwStyleCount și IpStyle Alinierea la centru Acceptat numai pe Windows NT/ PS ALTERNATE Alternarea între distanțe de pixeli Acceptat numai pe Windows NT/ și doar pe pixuri cosmetice Completare PS ENDCAP ROUND Capăt rotunjit (jumătate de cerc adăugată la linie) Numai stilou geometric PS ENDCAP SQUARE Capăt pătrat (adaugă jumătate de pătrat la o linie) Numai stilou geometric PS ENDCAP FLAT Finisaj plat Numai pixuri geometrice Compus PSJOINBEVEL Unire trunchiată Numai stilou geometric PS JOIN MITER Numai pixuri geometrice cu îmbinare ascuțită PSJOINROUND Numai pixuri geometrice cu îmbinare rotundă Penele extinse sunt împărțite în două tipuri: cosmetice și geometrice Parametrul dwWidth specifică lățimea stiloului Pentru pixurile cosmetice, greutatea poate fi doar Pentru pixurile geometrice, greutatea este specificată în coordonate logice, astfel încât greutatea reală a liniei depinde de transformările lumii și de maparea ferestrelor în fereastra de vizualizare Pixurile extinse folosesc structura LOGBRUSH pentru a defini culorile și modelele Pixurile cosmetice permit doar culori solide și umpluturi solide, în timp ce pixurile geometrice permit culori și modele mixte pene perii Ultimii doi parametri ai ExtCreatePen definesc o regulă personalizată de rotație a pixelilor pentru stilourile în stil PSJJSERSTYLE pene cosmetice Pixurile cosmetice desenează întotdeauna linii grosime de un pixel Deși MSDN afirmă că pixurile cosmetice au o lățime arbitrară specificată în sistemul de coordonate al dispozitivului, singura valoare validă pentru parametrul dwWidth este ; pentru orice altă valoare, apelul funcției eșuează Windows NT/ a introdus două noi stiluri: PSJJSERSTYLE și PS ALTERNATE Stilul PS ALTERNATE poate fi folosit numai în pixurile cosmetice pentru a crea linii punctate „adevărate” Stilul PS USERSTYLE permite unei aplicații să-și definească propriile secvențe de pixeli (biți de stil) Sunt necesari doi parametri suplimentari pentru a crea un stilou personalizat, dwStyle eCount (un tip DWORD) și IpStyle (o matrice DWORD) Primul element al matricei conține lungimea primului segment, al doilea - lungimea decalajului, al treilea - lungimea celui de-al doilea segment și așa mai departe În acest caz, o unitate corespunde la trei pixeli în loc de unul Prin urmare, stilul personalizat vă permite să emulați stilurile PSDASH, PS DOT, PS DASHDOT și PS DASHDOTDOT, dar nu și stilul PS ALTERNATE Fragmentul de mai jos creează un creion cosmetic cu o alternanță de { , , , }, adică un interval de pixeli, un interval de pixeli, un interval de pixeli și un interval de pixeli const DWORD cycle[ ] = { , , }; const LOGBRRUSH pensula = {BS SOLID RGB(OOOxFF) }; HPEN hPen = ExtCreatePen(PS COSMETIC | PSJJSERSTYLE, și pensulă, dimensiunea(ciclului)/dimensiunea(ciclului[ ]), ciclu): La prima vedere, pixurile cosmetice par a fi similare cu pixurile simple create de funcția CreatePen cu o lățime de Cu toate acestea, au o diferență importantă nedocumentată (sau poate un defect de implementare): pixurile cosmetice desenează întotdeauna în mod transparent Cu alte cuvinte, chiar și atunci când modul de umplere a fundalului este setat la OPAC, pixelii de fundal din spații nu sunt afișați Stilurile de pene cosmetice sunt prezentate în fig Pentru linii de stil personalizat, ciclul de alternanță este { , , , } Notă: PS INSIDEFRAME este un stil de stilou cosmetic nevalid, care nu se convertește automat într-un stil de linie continuă PS SOLID PS DASH PS DOT PS DASHDOT PS DASHDOTDOT PS NULL PSJNSIDEFRAME PSJJSERSTYLE PS ALTERNATE ■■■■■■■■■■■■■■■■■■□□□□□□■■■■■■■ □□□□□□□□□□□□□□□□□□□□□□□□□□□□□□ Orez Stiluri de stilouri cosmetice Capitolul După cum sugerează și numele, pixurile cosmetice sunt excelente pentru a desena linii fine, în special pe un ecran de monitor Când sunt randate în contextul unui dispozitiv de imprimantă cu rezoluție mai mare, liniile de stil apar ca linii continue mai deschise și chiar și liniile continue sunt vizibile numai atunci când există un contrast ridicat cu culoarea de fundal pene geometrice Pixul geometric desenează o linie cu un „vârf” sub forma unei figuri geometrice Mai precis, un stilou geometric are o grosime, stil, finisaj și conexiune variabile Să ne uităm la aceste atribute mai detaliat Grosimea unui stilou geometric este specificată în coordonate logice, dar spre deosebire de stilourile create de funcția CreatePen, grosimea unui stilou geometric nu poate fi Grosimea fizică reală a unui stilou geometric este mai complicată În modul MM TEXT cu conversie de identitate, o unitate logică a dispozitivului este convertită într-o unitate fizică, astfel încât grosimea fizică este aceeași cu cea logică Dacă transformarea lumii și maparea fereastră-la-vizualizare utilizează aceeași scară pe ambele axe, grosimea creionului logic este scalată în funcție de factorul de scară specificat Dar dacă scara este diferită, liniile verticale și orizontale desenate cu același stilou cu geometrie vor avea grosimi diferite Acest lucru se aplică și pixurilor create cu funcția CreatePen O linie trasată cu un stilou geometric nu este tratată ca o simplă succesiune de pixeli, ci ca o figură geometrică De exemplu, o linie ( , )-( , ) desenată cu un stilou de lățimi are forma unui dreptunghi definit de unghiuri opuse ( , ) și ( , ) Transformările lumii și modul de afișare se aplică liniilor la fel de mult ca și dreptunghiurilor Pe fig prezintă punctele de control ale dreptei geometrice rotite (x , y (Y) - (x , yG) dx = lățimea stiloului * sin(o]/ dy = pen width * cos(o]/ (x -dx,y +dy) (x -dx,y +dy) (x ,y (x ,y ) (x +dx,y -dy) (x +dx,y -dy) Orez Linia geometrică ca figură geometrică pene Atributul final al unei linii geometrice determină tipul de „capete” adăugate la ambele capete ale liniei sau la segmentele sale interne Linia prezentată în figură este trasată fără terminații, ceea ce corespunde stilului PS ENDCAP FLAT (terminare plată) Liniile îngroșate desenate cu pixuri simple au capace semicirculare (PS ENDCAP ROUND) adăugate la ambele capete Cu un capăt pătrat (PS ENDCAP SQUARE), jumătate de pătrate sunt atașate la ambele capete În Windows NT/ , toate stilurile sunt implementate pentru pixurile geometrice, cu excepția stilului PS ALTERNATE, care este rezervat liniilor cosmetice Spre deosebire de pixurile simple create cu funcția CreatePen, liniile geometrice groase sunt desenate în funcție de stilul lor și nu sunt convertite în linii continue Pixurile geometrice nu reprezintă un punct cu trei pixeli; în schimb, dimensiunea punctului sau a liniei este scalată cu grosimea liniei În acest caz, un punct este reprezentat de un pixel, ca atunci când utilizați linii cosmetice cu stilul PS ALTERNATE Pe măsură ce stiloul devine mai gros, dimensiunea punctelor crește și ea Fiecare segment sau punct este alcătuit prin terminațiile corespunzătoare Prin urmare, segmentele de linii întrerupte se pot termina în capete plate, rotunde sau pătrate Din păcate, în Windows / , implementarea Win GDI API arată oarecum diferit În aceste sisteme, bazate pe versiunile GDI pe biți, pixurile geometrice groase sunt implementate ca linii continue Penele geometrice nu se mai limitează la o singură culoare solidă Funcției ExtCreatePen i se transmite o structură LOGBRUSH care conține informații despre culoare, stilurile pensulei și stilul de contur Structura LOGBRUSH este utilizată de obicei pentru a defini pensulele logice pentru umplerea formelor Cu toate acestea, liniile geometrice nu diferă fundamental de formele geometrice, așa că este firesc ca GDI să vă permită să pictați peste ele cu pensule Pe fig Figura prezintă linii geometrice cu diferite finisaje, stiluri și modele Rețineți că stilul PS ALTERNATE pentru linii geometrice este considerat invalid, iar stilul PS NULL nu desenează nimic Spre deosebire de pixurile cosmetice, pixurile cu geometrie desenează linii în modul transparent, ignorând culoarea și modul de umplere a fundalului (cu o singură excepție - atunci când lucrați cu o pensulă de contur, aceste atribute sunt folosite pentru a umple fundalul între linii) De asemenea, merită remarcat faptul că cantitatea de goluri în stilul personalizat este setată în pixeli, nu în unități logice, care se modifică odată cu grosimea stiloului Cu un stilou mai gros sau cu adăugarea de terminații, segmentele de linie în linii de stil personalizat se pot „strecura” unele peste altele Este posibil ca joncțiunile liniilor groase cu terminații să nu arate așa cum v-ați aștepta Pe fig arată cum arată litera Z, constând din trei linii îngroșate cu capete diferite Liniile subțiri albe indică poziția axelor de bază Figura arată terminațiile create de stilurile PS ENDCAP SQUARE și PS ENDCAP ROUND Capetele plate și pătrate sunt îmbinate neuniform Deși liniile cu capete rotunde se unesc în mod normal, atunci când utilizați modul R X RPEN, părțile comune ale liniilor vor diferi ca culoare deoarece sunt desenate de două ori Capitolul PS SOLID PS DASH PS DOT PS DASHDOT PS DASHDOTDOT PS NULL PSJNSIDEFRAME PSJJSERSTYLE PS ALTERNATE w= plat w= , plat w= , pătrat w= , rotund, trapă Orez Linii geometrice cu grosimi, terminații, hașurare și stiluri diferite PS ENDCAP FLAT Orez Contactul liniilor cu terminații diferite PS ENDCAP ROUND R XORPEN Pentru a asigura îmbinarea lină a liniilor, GDI vă permite să combinați mai multe linii și curbe într-un singur apel grafic Când se folosește un stilou cu geometrie pentru a desena o linie sau o curbă care constă din mai multe segmente, felul în care se unesc segmentele este determinat de un atribut special, conexiunea Există trei tipuri de conexiuni Legatura trunchiata este construita sub forma a doua segmente cu legaturi plate; se adaugă un triunghi la articulație pentru a umple depresiunea O conexiune ascuțită este construită într-un mod similar, dar în acest caz liniile continuă până la punctul de intersecție O conexiune rotunjită arată la fel ca atunci când unești două linii cu capete rotunde Pe fig Figura - prezintă aceeași figură în formă de Z desenată cu funcția Polyline GDI, care vă permite să desenați mai multe linii cu diferite tipuri de conexiuni într-un singur apel Pe lângă îmbunătățirea aspectului conexiunilor, funcția Polyline desenează fiecare pixel o singură dată, așa că chiar dacă utilizați operația R X RPEN, întreaga linie va fi desenată într-o singură culoare PS ENDCAP FLAT PS ENDCAP SQUARE PS JOIN BEVEL PS JOIN MITER PS ENDCAP ROUND PS ENDCAP ROUND PS JOIN ROUND PS JOINJU)UND R XORPEN Orez Tipuri de conexiune atunci când utilizați funcția Polyline pene La unirea liniilor la unghiuri ascuțite, lungimea conexiunii ascuțite poate fi foarte mare Pentru a evita supraextinderea cusăturilor, GDI permite unei aplicații să limiteze lungimea unei cusături conice folosind funcția SetMiterLimit: BOOL SetMiterLimit(HDC hDC FLOAT eNewLImlt PFLOAT peOldLimlt); Funcția SetMiterLimit definește limita unghiulară, care este raportul maxim dintre lungimea cuspidei și lățimea liniei În a doua figură din stânga (vezi Fig ), lungimea conicității este egală cu distanța de la intersecția limitelor exterioare ale liniei până la intersecția limitelor interioare Grosimea stiloului este egală cu distanța dintre cele două intersecții de-a lungul axei y Limita unghiulară implicită în contextele dispozitivului este În figură, raportul este de aproximativ , Dacă raportul dintre lungimea conică și grosimea liniei depășește limita unghiulară, se folosește o conexiune trunchiată în locul unei conexiuni conice Dacă preferați abordarea matematică, atunci când două drepte se intersectează la un unghi Ѳ, raportul unghiular este dat de expresia l/sin( / ), independent de grosimea stiloului În exemplul de mai sus, lățimea formei Z este de două ori înălțimea ei, deci sin( ) = /V , sin( / ) = , și raportul unghiular este , Obținerea de informații despre stilourile logice Din mânerul cunoscut al obiectului stilou logic, o aplicație poate învăța tipul stiloului și poate obține o descriere a acestuia folosind două funcții comune: DWORD GetObjectType(HGDIOBJ h); int GetObject(HGDIOBJ hgdlobj Int cbBuffer, LPVOID IpvObject); Funcția GetObjectType returnează identificatorul de tip de obiect GDI Pentru un stilou simplu, constanta OBJ PEN este returnată; pentru un stilou extins, OBJ EXTPEN este returnat Funcția GetObject umple un buffer cu definiția unui obiect GDI Pentru pixurile simple, structura LOGPEN este umplută; iar pentru cele extinse, structura EXTLOGPEN Structura LOGPEN are o dimensiune fixă, așa că funcția GetObject funcționează foarte bine pentru un stilou simplu Cu toate acestea, structura EXTLOGPEN are o lungime variabilă datorită matricei de descriere a stilului, deci funcția GetObject trebuie apelată de două ori La primul apel, se determină dimensiunea exactă a structurii EXTLOGPEN, iar la al doilea apel, blocul de memorie alocat de dimensiunea necesară este umplut În API-ul Win , aceste apeluri în doi pași sunt destul de comune Fragmentul de mai jos arată cum să utilizați aceste două funcții pentru a popula o structură LOGPEN sau EXTLOGPEN, în funcție de tipul de mâner al obiectului stilou LOGPEN logpen: EXTLOGPEN * pextlogpen = NULL; int dimensiune = ; comutator ( GetObjectType(hPen) ) { carcasă OBJ-PEN: GetObject(hPen, sizeof(logpen), & logpen): break; Capitolul caz OBJ EXTPEN: dimensiune = GetObject(hPen O, NULL): pextlogpen = (EXTLOGPEN *) caracter nou [dimensiune]; GetObject(hPen, dimensiune, pextlogpen): break: Mod implicit: } dacă (pextlogpen) { delete[] (char *) pextlogpen; pextlogpen=NULL; } Clasă pentru lucrul cu obiecte stilou GDI Pentru a utiliza un obiect stilou personalizat, trebuie să îl creați și să îl selectați în contextul dispozitivului; după utilizare, obiectul este scos din context și eliminat Acest lucru este ușor de făcut, dar nu foarte interesant Mai jos este o clasă simplă KPen C++ concepută pentru a funcționa cu stilouri simple și stilouri extinse obișnuite // Clasa pentru selectarea obiectelor GDI clasa KSelect { HGDIOBJ m h d: HDC m hDC: public: void Select (HDC hDC HGDIOBJ hObject) { dacă(hDC) m hDC=hDC: m h d = SelectObject(hDC, hObject): } el se { m hDC - NULL; m h d = NULL; } } void UnSelect(void) { dacă ( m hDC ) { SelectObject(m hDC m h d); m hDC=NULL: m hold = NULL; pene // Clasa pentru lucrul cu obiecte stilou clasa KRep : public KSelect { public: HPEN m hPen; KPen(stil int lățime int culoare COLORREF, HDC hDC=NULL) { m hPen = CreatePen(stil lățime, culoare); Selectați(hDC); } KPen(int style, int width COLORREF culoare, int count DWORD *gap HDC hDC=NULL) LOGBRUSH logbrush = { BS SOLID, culoare }; m hPen = ExtCreatePen(stil, lățime & perie de lemn număr decalaj); Selectați(hDC); } void Select (HDC hDC) { KSelect::Select(hDC m hPen): } -KPenO { UnSelect(); DeleteObject(m hPen): } } Clasa CRep conține doi constructori Primul constructor creează pene simple, în timp ce al doilea constructor creează pene extinse fără o pensulă de model În principiu, puteți scrie un alt constructor care ar crea pene extinse cu o perie de model Ambii constructori primesc un parametru opțional, handle-ul de context al dispozitivului Dacă acest parametru este setat, mânerul stiloului GDI generat este selectat în contextul dispozitivului specificat Destructorul scoate stiloul din context dacă este încă selectat și elimină obiectul Cele două metode suplimentare sunt pentru selectarea explicită și excluderea mânerului stiloului din context Aplicarea clasei CRep este extrem de simplă Dacă se folosește un singur stilou într-un fragment, includeți o instanță a clasei KRep în blocul corespunzător, transmiteți mânerul de context al dispozitivului constructorului și crearea ulterioară a obiectului GDI, selectarea acestuia în context, ștergerea și ștergerea vor fi efectuată automat Dacă fragmentul de cod funcționează cu mai multe stilouri, nu transmiteți mânerul de context constructorului; în schimb, ar trebui să apelați metodele Select și UnSelect la momentele potrivite Să ne uităm la câteva exemple simple { crep red(PS SOLID RGBCOxFF ) hDC); // Desenați cu stiloul roșu Capitolul // Când acest bloc iese, stiloul // este automat eliminat din context și distrus } { KPen roșu(PS SOLID , RGBCOxFF, , )); KPen verde(PS SOLID, RGB( OxFF )); roșu Selectați(hDC): // Desenați cu stiloul roșu red UnSelect(hDC): verde Selectați (hDC): // Desenează cu stiloul verde verde UnSelect(hDC): // La ieșirea din bloc, ambele stilouri sunt eliminate automat } linii După ce a fost selectat un mâner de obiect stilou logic valid în contextul dispozitivului, puteți utiliza următoarele funcții pentru a desena linii drepte (fie individual, fie în mai multe) și pentru a vă pregăti pentru trasarea liniilor: BOOL MoveToEx(HDC hDC Int X Int Y LPPOINT IpPoint); BOOL L neTo(HDC hDC Int nXEnd, int nYEnd): BOOL Polyl neTo(HDC hDC CONST POINT * Ippt DWORD cCount): BOOL PolylineCHDC hDC PUNCT CONST * Ippt Int cPoints): BOOL PolyPolyl ne(HDC hDC PUNCT CONST * Ippt, CONST DWORD * IpdwPolyPoints DWORD nCount): Funcția MoveToEx nu desenează linii - ci doar mută poziția curentă a stiloului în contextul dispozitivului până la punctul de la coordonatele date Poziția inițială este returnată în parametrul IpPoint Funcții precum LineTo, PolylineTo, PolyBezierTo și chiar funcțiile de ieșire a textului încep producția la poziția curentă a stiloului Toate coordonatele sunt date în spațiu logic Funcția LineTo trasează o linie de la poziția curentă a creionului la punct (nXEnd, nYEnd) și traduce poziția curentă în punct (nXEnd, nYEnd) Aspectul liniei depinde de toate atributele descrise în secțiunea anterioară Alte atribute ale contextului dispozitivului pot fi, de asemenea, luate în considerare în procesul de randare, cum ar fi transformarea lumii, modul de afișare, funcționarea raster binar, modul de umplere a fundalului, culoarea de fundal și limita de colț În acest caz, trebuie luate în considerare o serie de circumstanțe În primul rând, pixelul spațiului de coordonate fizic mapat la (nXEnd, nYEnd) nu este desenat, dar este desenat punctul de plecare De exemplu, dacă desenați o linie de la un punct ( , ) la un punct ( , ) cu o mapare identică de la coordonatele logice la coordonatele fizice, pixelii ( )-( ) sunt desenați, dar niciun pixel nu este desenat linii ( , ) Aceasta mută poziția curentă a stiloului în punctul ( , ), astfel încât acel punct va fi desenat atunci când următoarea linie este trasă din acel punct Dacă desenați mai multe linii conectate cu funcția LineTo, fiecare pixel, cu excepția ultimului, este desenat exact o dată Această condiție este păstrată în timpul translațiilor, scalarilor, rotațiilor și altor transformări ale spațiului de coordonate Când o linie este trasată folosind operații binare raster, cum ar fi R X RPEN, punctele de conectare a segmentului de linie nu arată diferit de alți pixeli Dacă funcția LineTo ar desena ultimul pixel, punctele de cusătură ar fi desenate de două ori și, prin urmare, ar fi afișate în culoarea de fundal Din cauza acestei reguli și din alte motive, operațiunile de desenare sunt direcționale Cu alte cuvinte, pentru două puncte (x , y ) și (x , y ), linia trasă de la (x , y ) la (x , y ) este oarecum diferită de linia trasă de la (x , y ) la (x ) , y ) De asemenea, rețineți că fiecare apel la funcția de desenare a liniilor cu creionul de stil repornește ciclul de alternanță a pixelilor Combinarea stilurilor de linii diferite (ceva ca schimbarea punctului de bază al unei pensule) nu este acceptată în GDI De exemplu, pentru trei puncte (x , y ), (x , y ) și (x , y ) situate pe aceeași linie dreaptă, rezultatul trasării a două linii (x , y ) - (x , y ) și (x ) , yG) - (x , y ) poate diferi de rezultatul trasării unei linii (x , y ) - (x , y ) Următorul fragment folosește funcțiile MosheToEx și LineTo pentru a desena o rozetă, un poligon cu fiecare vârf conectat la fiecare alt vârf Culoarea liniei depinde de distanța dintre vârfuri Acest fragment folosește un stilou DC pentru a facilita schimbarea culorilor, dar este ușor să îl înlocuiți cu un stilou simplu const intN= ; const int Raza = : const dublu teta = , * / N: SelectObject(hDC, GetStockObject(DC PEN)); const COLORREF culoare[] = { RGB(O, , ) RGB( , , ) RGB( , , ) RGB( , , ) RGB( ) RGB(O ) RGB( ) RGBC , ) RGB(O ) RGB( ) }: pentru (int p= ; p P este determinat de formula P (t) = (lt)Pl + tP Segmentul P -»P este format din valorile funcției P ( când t se schimbă de la la Dacă adăugăm un alt punct P în plan, putem defini P ( ca punct între P și P și P (O) ca punct între P și P Dacă acum aplicăm o metodă similară pentru a determina P ( ca un punct între P ( și P (O>) obținem: P (t) = (lt)Pl + tP P (t) = (lt)P + tP P (t) = (lt)(lt)Pl + tP ) + t((lt)P + tP ) = (lt)A Pl + t(tl)P + Г РЗ Punctele descrise de funcția PI ( ) nu formează o linie dreaptă când t se schimbă de la la Avem o curbă pătratică, sau o curbă parabolică de ordinul doi Această metodă de definire a curbelor a fost inventată de P de Casteljau în Mai târziu, în , teoria acestor curbe a fost re-dezvoltată de P Bezier (R Bezier) în procesul de lucru asupra sistemelor de proiectare asistată de calculator pentru Citroen și Renault Bezier a fost primul care le-a introdus pe acestea curbe către publicul larg, așa că sunt cunoscute sub numele de curbe Bezier Curbele Bezier pătratice sunt folosite în fonturile TrueType pentru a descrie contururile glifelor Grafica computerizată este caracterizată de curbe definite de patru puncte așa cum este descris mai sus Astfel de curbe sunt numite curbe Bézier cubice Pe fig arată procesul de construire a unei curbe Bezier cubice folosind următoarele formule: P (t) = (lt)Pl + tP P (t) = (lt)P + tP P (t) = (lt)P + tP P (t) = ( ЧГ Р + t(tl)P + t* P P (t) = (lt)* P + t(tl)P + Г Р P(t) = ( - GZR + (lt)* tP + (lt)tx P + GZR Procesul ilustrat în figură este denumit în mod obișnuit algoritmul lui de Castelo Punctele PI, P , P și P care definesc curba Bezier sunt numite puncte definitorii ale acesteia Punctele P și P sunt numite puncte finale, iar punctele P și P sunt numite puncte de control Curbele Bezier au o serie de proprietăți interesante care le fac utilizate pe scară largă în proiectarea și fabricarea asistate de computer O Invarianță afină Curbele Bezier, ca rezultat al transformărilor afine utilizate de GDI atunci când sunt afișate din sistemul de coordonate mondial la coordonatele paginii, se transformă în curbe Bezier Prin urmare, motorul grafic trebuie doar să convertească punctele de potrivire și să deseneze o curbă în coordonatele dispozitivului peste punctele convertite Capitolul Orez Construirea unei curbe Bezier cubice din patru puncte definitorii O limitare O curbă Bézier se află întotdeauna în întregime într-o figură convexă ale cărei vârfuri sunt punctele ei definitorii Despre tangente la punctele finale Linia care leagă punctele P și P este tangentă la curba în punctul P ; linia care leagă punctele P și P este tangentă la curba în punctul P Pentru ca două curbe Bezier (P , P , P , P ) și (P , P , P , P ) să se conecteze fără probleme (adică cu o derivată întâi continuă), este suficient ca punctele P , P și P sunt pe aceeași linie Oh divizibilitate O curbă Bezier este ușor împărțită în două curbe Bezier Curba prezentată în fig poate fi împărțit cu ușurință în două curbe care se unesc în punctul P; prima curbă este determinată de puncte (P , P , P , P), iar a doua de puncte (P, P , P , P ) Pe baza proprietății de divizibilitate, se construiește un algoritm pentru trasarea curbelor Bezier ca un set de linii drepte Curba Bezier este împărțită la mijlocul (t = , ), după care cele două curbe rezultate sunt împărțite recursiv până atunci până când punctele de control sunt suficient de aproape de linie pentru a reprezenta curba ca un segment de linie Funcția recursivă pentru potrivirea curbelor Bezier este prezentată în Lista În primul rând, funcția verifică dacă punctele (x ,z/ ) și (x ,z/ ) sunt la mai puțin de o unitate distanță de linia (x ,y ) - {x ,y ) Dacă această condiție este îndeplinită, funcția trasează o linie dreaptă; în caz contrar, curba este împărțită la mijloc în două curbe, a căror ieșire este efectuată printr-un apel recursiv Precizia calculelor este asigurată prin utilizarea numerelor în virgulă mobilă Lista Desenați curbe Bezier din segmente de linie void BezlerCHDC hDC dublu xl dublu yl, dublu x , dublu y dublu x dublu y , dublu x dublu y ) curbe Bezier dublu A = y - yl; dublu B \u d xl - x : dublu С = yl * (x -xl) - xl * (y -il); // Ax + Vy + C = - linie (xl yl) - (x , y ) dublu AB = A* A + B* B; // Distanța de la (x ,y ) la linie este mai mică de // Distanța de la (x y ) la linie este mai mică de dacă ( (A*x + B*y + C)*(A*x + B*y + C) P ; coordonatele x ale tuturor celor patru puncte de control sunt sortate în ordine crescătoare Schimbarea poziției punctelor de control duce la o schimbare radicală a aspectului curbei Următorul fragment (Listing ) desenează o secvență de cinci curbe Bezier folosind funcția PolyBezler Capitolul Lista Desenarea unei serii de curbe Bezier folosind funcția PolyBezier HPEN hRed = CreatePen(PS DOT, O, RGEKOxFF, O, )); HPEN hBlue = CreatePen(PS SOLID RGB(O O, OxFF)): pentru (Int z= : z = ) // Dacă unghiul este mai mare de de grade -eSweepAngle = ; // părăsesc cercul complet else if (eSweepAngle ) dir = SetArcDirection(hDC, AD COUNTERCOCKWISE): altfel dir = SetArcDirection(hDC AD CLOCKWISE); // Unghiul este setat în sistemul de coordonate al dispozitivului BOOL rslt = ArcTo(hDC X - dwRadius, Y - dwRadius, X + dwRadius, Y + dwRadius, X + (int) (dwRadius * * cos(eStartAngle)), Y - (int) (dwRadius * * sin(eStartAngle)), X + (int) (dwRadius * * cos(eEndAngle)), Y - (int) (dwRadius * * sin(eEndAngle))): SetArcDirection(hDC, dir): return rslt: } Funcția se asigură că arcul desenat nu este mai mare decât un cerc complet, convertește grade în radiani, setează direcția arcului în funcție de semnul dimensiunii unghiulare, calculează punctele de început și de sfârșit (în timp ce înmulțește raza cerc cu pentru a îmbunătăți acuratețea), apoi desenează arcul funcției ArcTo Desenați arcuri cu stiloul cu stilul PS INSIDEFRAME Deoarece arcele sunt limitate la dreptunghiuri, iar interiorul unui arc este ușor de distins de exterior, GDI respectă stilul stiloului PS INSIDEFRAME Când un stilou cu acest stil este folosit pentru a desena un arc, linia centrală a curbei se deplasează spre interior cu jumătate din grosimea stiloului Pixelii exteriori ai liniei ating caseta de delimitare, iar restul pixelilor sunt desenați în interiorul casetei Când desenați arce, folosirea unui stilou cu stilul PS INSIDEFRAME este foarte simplă - doar reduceți caseta de delimitare cu jumătate din grosimea stiloului A face același lucru în cazul general (de exemplu, pentru o serie închisă de curbe Bezier) este mult mai dificil arcuri Rețineți că stilul stiloului PS INSIDEFRAME este definit la același nivel cu PS SOLID sau PS DOT și nu este un atribut de linie precum atributele de terminare și conexiune, de exemplu Drept urmare, penele interioare sunt întotdeauna solide Această proprietate ar trebui probabil implementată ca un atribut de stilou independent Conversia arcelor în curbe Bezier Probabil ați realizat deja că desenarea curbelor nu este o sarcină ușoară Pentru a determina cât de mult din perimetrul elipsei trebuie desenat, trebuie să utilizați calcule cu virgulă mobilă și să vă ocupați de atributul de direcție al arcelor Și mai rău, puteți desena doar părți ale elipselor care au axe care sunt paralele cu axele sistemului de coordonate logic Dacă doriți să desenați un arc după o rotație sau o translație, va trebui să calculați transformarea necesară, iar această caracteristică nu este acceptată pe sistemele de operare care nu sunt din familia NT Curbele Bezier vin în ajutor Operațiile cu ele sunt foarte simple, iar calculele în procesul de desenare sunt destul de elementare Ca rezultat al transformărilor afine, o curbă Bezier este mapată la o curbă Bezier, iar rezultatul este întotdeauna unic, deoarece patru puncte definesc exact o curbă Singura întrebare care rămâne este cum se construiește o curbă Bezier aproximând un arc eliptic? O aproximare a unui cerc complet a unei singure curbe Bezier are o eroare prea mare Chiar și reprezentarea unei jumătate de cerc cu o singură curbă Bezier nu garantează o precizie suficientă Să încercăm să calculăm pozițiile punctelor de control pentru o curbă Bezier care aproximează un sfert de cerc ( de grade) Pentru un sfert de cerc unitar situat în primul cadran al sistemului de coordonate carteziene, cunoaștem punctele de capăt ( , ) și ( , ) Arcul de de grade este simetric față de linia X=Y, deci cele două puncte de control trebuie să fie și ele simetrice Știm că linia trasată de la punctul de început până la primul punct de control este tangentă la arcul din punctul de început Aceasta înseamnă că linia trebuie să treacă la un unghi de grade, adică primul punct de control trebuie să aibă coordonatele (l??, ) pentru variabila necunoscută m Prin simetrie, al doilea punct de control trebuie să aibă coordonate ( , t) Deci, cunoaștem toate cele patru puncte de control P :( , ), P :(xm, ), P ( ,m) și P ( , ); Tot ce rămâne este să găsim variabila necunoscută Pe fig Figura prezintă arcul de de grade al cercului unitar din primul cadran O polilinie ușoară conectează cele patru puncte ale curbei Bezier pe care încercăm să o găsim Cele șase curbe de lumină arată aproximări ale curbei Bezier, deoarece m variază de la la , în trepte de , Curba întunecată ilustrează arcul aproximat Punctul de mijloc al curbei se calculează prin înlocuirea valorii t = , în formula din secțiunea anterioară: Р( , ) = (ІЧГЗРІ + (lt)A tP + (lt)tA P + tA P = (PI + ZR + ZRZ + P )/ Capitolul m= , , ergo( , ) = + , % Orez Convertiți arcul de de grade în curba Bezier Dacă calculăm punctul de mijloc al curbei ( , ), (m, ), ( ,/u) și ( , ) folosind această formulă, obținem: Xmid = ( + m+ +l)/ = ( m + )/ Ymid = (l+ + m+l)/ = ( m + )/ Se știe că în cercul unitar punctul (Xmid, Ymid) are coordonate (>/ / , / ), deci m = (n/ - )/ sau aproximativ m = , Dacă utilizați patru dintre aceste curbe Bézier pentru a aproxima o elipsă completă, la toate unghiurile care sunt multiple de de grade, curba Bézier se va potrivi exact cu cercul Rămâne doar să înțelegem cât de aproape va fi de restul punctelor? Variind t de la la , în incremente mici, putem obține coordonatele punctelor curbei Bezier, putem calcula distanța lor de la origine și putem compara aceasta cu distanța pentru cercul unitar Cea mai mare eroare relativă este de , % și se realizează la t = , Care este dimensiunea acestei erori în pixeli? Când desenați o elipsă care ocupă întregul ecran (de obicei, nu mai mare de x pixeli), aproximarea -bezier se abate de la curba adevărată cu , pixeli în cel mai rău caz Lista prezintă două funcții Prima funcție, EllipseToBezier, desenează o elipsă completă aproximată prin curbele Bezier Acesta calculează puncte de potrivire pentru patru curbe Bezier folosind cele de mai sus arcuri cale A doua funcție, AngleArcToBezier, desenează un arc cu unghiuri de început și de sfârșit arbitrare, aproximându-l cu o singură curbă Bezier Lista Desenarea perimetrului unei elipse folosind curbele Bezier BOOL El ipseToBezier(HDC hDC, Int stânga, int sus, Int dreapta, Int jos) { const dublu M = , ; PUNCTUL P[ ]: Int dx = (int) ((dreapta - stânga) * ( -M) / ); int dy = (int) ((jos - sus) * ( -M) / ); P[ ] x = dreapta; // P[ ] y = (sus+jos)/ ; // P[ x = dreapta; și p[ Yu-U = top + dy; // R[ x = dreapta - dx; // P[ ] Y = sus; // , P[ x = ( stânga+dreapta)/ ; // P[ y = sus; // // P[ x = stânga + dx; // P[ -Y = sus; P[ x = stânga; P[ -Y = top + dy; R[ s = stânga; P[b] y = (sus+jos)/ ; p[ x = stânga: P[ -Y = fund - dy; P[ x = stânga + dx; P[ ] y = fund; Р[ x = ( stânga+dreapta)/ ; P[ ] y = fund; P[ ] x = dreapta - dx; P[ ],y = fund; P[ll] x = dreapta; P[ll] y = fund - dy; P[ ] x = dreapta; P[ ],y = (sus+jos)/ ; returnează PolyBezier(hDC P, ); BOOL AngleArcToBezier(HDC hDC, int xO, int yO, int rx, int ry, dublu startangle double sweepangle, double * err) { dubluXYL ]; POINTP[ ]; // Calculați curba Bezier pentru arc, Continuare & Capitolul Lista Continuare // simetric față de axa x // În sens invers acelor de ceasornic: (O,-B), (x,-y), (x y), (O,B) dublu B = ry * sin(sweepangle/ ): dublu C = rx * cos(sweepangle/ ); dublu A = rx - C: dublu X = A* / : dublu Y = B - X * (rx-A)/B: XY[O] = C: XY[ ] = - B; XY[ ] = C+X; XY[ ] = - Y; XY[ ] = C+X; XY[ ] = Y: XY[ ] = C; XY[ ] = B; // Întoarcerea la colțul original dublu s = sin(startangle + sweepangle/ ): dublu c = cos(startangle + sweepangle/ ): pentru (int = : i ) { njpPoint = POINT nou[m nCount]: njpFlag = nou BYTE[mjiCount]; if ( m pPoint!=NULL && m pFlag!=NULL ) mjiCount = ::GetPath(hDC, m pPoint, njpFlag, mjiCount); el se mjiCount= : returnează mjiCount; } void MarkPoints(HDC hDC, bool b$howLine=true); b Funcția GetPath vă ajută să înțelegeți cum sunt implementate diferitele funcții de ieșire a liniilor și curbei în GDI, deoarece puteți vedea datele căii cu aceasta De exemplu, dacă doriți să știți cum este convertit AngleArc în curbele Bezier, încercați următorul fragment: BeginPath(hDC); MoveToEx(hDC, , NULL); AngleArc(hDC, , , , , ); PUNCTUL P[] = { - , , - , - , , - }; PolyBezier(hDC, P, ); CloseFigure(hDC): EndPath(hDC); KPathData org; org GetPathData(hDC); Capitolul Între apelurile către BeginPath și EndPath, sunt efectuate patru apeluri de funcție GDI Funcția MoveToEx mută poziția curentă a cursorului la origine, AngleArc desenează un arc de de grade, PolyBezler pictează o curbă Bezier pe arc, iar funcția CloseFigure închide forma După apelarea GetPathData, puteți vizualiza datele căii în fereastra de depanare, le puteți scoate într-un fișier text sau puteți eticheta grafic punctele de pe ecran În stânga în fig arată traiectoria definită de fragmentul de mai sus Ieșirea a fost realizată de funcția PolyDraw pentru datele returnate de GetPath În dreapta sunt punctele și steagurile returnate de funcția GetPath Punctul de pornire al formei este marcat cu un triunghi, punctele liniilor sunt marcate cu dreptunghiuri, punctele curbelor Bezier sunt marcate cu cercuri, iar punctul în care forma este închisă este indicat cu un marcator umplut Orez Datele de cale și cale returnate de funcția GetPath Puteți vedea din figură că AngleArc trasează o linie de la poziția curentă a stiloului ( , ) până la punctul de pornire al arcului ( , ); Un arc de de grade este reprezentat de două curbe Bezier Prima curbă Bezier desenează arcul inițial de de grade, iar a doua curbă desenează restul de ° Figura arată, de asemenea, că funcția CloseFigure nu include un segment suplimentar în datele de traiectorie, ci setează doar un steag pentru ultimul punct Documentația Microsoft nu definește clar unde ar trebui să fie indicatorul PT CLOSEFIGURE Este uneori atribuit în mod eronat primului punct de control al curbei Bezier Dar dacă analizați datele returnate de GetPath, totul devine absolut clar - indicatorul PT CLOSEFIGURE trebuie setat pentru ultimul punct al figurii Datele primite de la GetPath pot fi transmise direct în funcția PolyDraw, așa cum sa făcut pentru desenul din partea stângă a desenului Aceasta este o caracteristică extrem de utilă, mai ales având în vedere că GDI nu furnizează aplicațiilor cu un mâner pentru calea instrumentului Aplicația poate salva datele de traiectorie și le poate folosi în viitor Dacă doriți să desenați puncte în loc de curbe (în scopuri de editare, de exemplu), matricea de puncte returnată poate fi transmisă funcției Polyllne, așa cum sa făcut în partea dreaptă a figurii Înainte de a transmite date către GDI, acestea pot fi supuse oricăror transformări Rețineți că GDI acceptă doar transformări afine Traiectorii traducerile pe sistemele din familia NT și pe alte sisteme, transformările lumii nu sunt suportate deloc Implementarea transformărilor pentru a desena linii și curbe este ușoară Pentru transformările afine care mapează linii cu linii, este suficient să transformați toate punctele de control și apoi să desenați rezultatul cu aceleași steaguri Pentru transformările non-afine care pot mapa linii cu curbe, poate fi necesar să spargeți liniile și curbele în segmente mai mici pentru a îmbunătăți acuratețea Transformarea obiectului traseului de instrumente GDI definește două transformări pentru obiectele trasee: înlocuirea secțiunilor curbe cu altele drepte și îngroșarea liniilor Funcția FI attenPath convertește toate curbele obiect cale într-o secvență de segmente care oferă o aproximare rezonabilă a curbei în spațiul de coordonate logice Funcția FI attenPath este limitată la transformarea curbelor Bezier Acesta folosește un algoritm recursiv ca cel din Listarea , împărțind curba la jumătate până când eroarea este neglijabilă Numele funcției dă impresia greșită că duce la o distorsiune semnificativă a curbei De fapt, funcția FI attenPath oferă cea mai bună aproximare în coordonate logice Desigur, reprezentarea întregului are ca rezultat o oarecare pierdere a preciziei, dar dacă rezultatul nu este scalat de un factor mare, diferențele sunt aproape imperceptibile Dacă rezultatul trebuie redat într-un context de dispozitiv de înaltă rezoluție, aplicația poate crește rezoluția spațiului de coordonate logice sau poate implementa propria sa versiune cu valoare reală a FI attenPath Funcția FI attenPath este apelată după ce EndPath a terminat de construit calea reală Modifică obiectul traiectorie curent în contextul dispozitivului Obiectul cale actualizat rămâne selectat în context și poate fi utilizat de alte funcții de cale (cum ar fi funcția GetPath) Cu o formă destul de complexă a traiectoriei, aproximarea poate necesita un consum considerabil de memorie Un exemplu de utilizare a funcției FI attenPath este ilustrat în fig Forma din stânga a fost desenată de funcția PolyDraw din datele returnate din apelul FIattenPath; aceeași cifră cu marcatori de puncte este afișată în partea dreaptă Figura din stânga este aproape aceeași cu figura din fig , totuși, când ne uităm la figura din dreapta, devine clar că punctele curbei au fost înlocuite cu un set de puncte liniare care reproduc destul de exact forma traiectoriei Sarcina de a converti curbele în linii drepte este adesea întâlnită în practică, deoarece este mult mai convenabil să lucrezi cu linii decât cu curbe Nu există formule simple care să vă permită să calculați lungimea curbei Bezier din punctele definitorii În sistemele CAD, utilizatorii lucrează cu modele create din curbele Bezier; conversia unei curbe într-un set de segmente facilitează calcularea lungimii acesteia Ca rezultat al aproximării liniare, o figură închisă se transformă practic într-un poligon și există mulți algoritmi gata pregătiți pentru calcularea ariei unui poligon, a casetei sale de delimitare și a verificarii intersecțiilor Capitolul mov Informațiile despre lungimea curbei sunt, de asemenea, utilizate la desenarea liniilor de stil Procesul de trasare a unei linii de stil poate fi reprezentat ca o alternanță multiplă a ieșirii segmentelor și intervalelor de lungime fixă Secțiunea „Exemplu: Desenarea liniilor de stil personalizate” arată modul în care aproximarea liniară a căilor vă poate ajuta să creați linii de stil personalizate Orez FlattenPath: potrivire curbă liniară Al doilea mijloc de conversie a căilor în GDI este funcția WidenPath Documentația Microsoft spune că WidenPath convertește calea curentă într-o zonă care ar fi umplută dacă calea ar fi desenată cu creionul selectat curent în contextul dispozitivului Notă: WidenPath convertește calea într-o regiune Dar o traiectorie este o traiectorie, cum poate fi o regiune? MSDN nu oferă nicio explicație în acest sens De fapt, WidenPath suprascrie calea curentă în jurul perimetrului zonei care ar fi umplută dacă calea ar fi desenată cu creionul curent Funcția WidenPath funcționează numai dacă stiloul actual nu este un stilou cosmetic creat de funcția ExtCreatePen Pentru pixurile create cu funcția CreatePen și pixurile geometrice create cu funcția ExtCreatePen, funcția WidenPath calculează perimetrul întregii zone, ținând cont de grosimea stiloului, stilul stiloului (inclusiv atributele de conectare și terminare) și limita de unghi Funcția WidenPath generează întotdeauna forme închise În plus, la fel ca FI attenPath, convertește curbele în linii (după cum sa menționat mai sus, liniile sunt mai convenabile de lucrat) După ce apelați WidenPath, nu mai trebuie să apelați FlattenPath, dar dacă apelați FlattenPath înainte de a apela WidenPath, calea generată va conține mai multe puncte (și segmente mai scurte) Rețineți o circumstanță importantă (cel puțin pe Windows NT/ ): pentru ca un stilou să fie eficient atunci când este apelat WidenPath, acesta trebuie selectat în contextul dispozitivului înainte de ultimul apel care produce ieșire grafică Dacă un stilou a fost selectat după ultima funcție de trasare, dar înainte de CloseFigure și EndPath, va fi folosit stiloul anterior Pe fig Figura prezintă o imagine destul de urâtă creată de funcția WidenPath Imaginile au fost construite pentru un stilou geometric de unități grosime, cu un vârf plat și o îmbinare ascuțită Funcția WidenPath convertește o formă închisă în două forme închise - prima extinde jumătate din lățimea traseului stiloului, iar a doua la fel Traiectorii valoarea intra Desigur, funcția WidenPath ar trebui să convertească calea deschisă într-o singură formă închisă care înconjoară calea originală cu jumătate din lățimea stiloului pe fiecare parte Dacă ar fi folosit un stilou de stil în loc de un stilou solid, ar fi generată o formă închisă separată pentru fiecare linie întreruptă sau punct Orez WidenPath convertește o formă închisă în două forme închise Traiectoria generată de funcția WidenPath este deja împărțită în segmente de linie dreaptă Dar se pare că GDI nu se limitează la un apel trivial la FI attenPath urmat de extinderea căii Dacă faceți acest lucru în aplicație, calea de instrumente generată va conține mai multe puncte și „bucle” Buclele urâte din figura din stânga apar atunci când două linii groase se ating la un unghi mai mic de ° Ele corespund zonelor suprapuse, care sunt desenate cu două linii separat Dacă rezultatul apelării WidenPath ar fi folosit doar pentru a implementa linii geometrice groase, buclele ar fi complet ascunse atunci când pictați forme închise Dar dacă aplicația dorește să folosească acest rezultat pentru a desena două forme închise, interioară și exterioară, va trebui să lucreze din greu la curățarea căilor Poate că funcția WidenPath, sau o implementare internă a acesteia, este folosită de GDI pentru a converti linii geometrice în zone care pot fi completate Acest lucru explică și de ce structura LOGBRRUSH este utilizată la definirea pixurilor logice geometrice, la fel ca atunci când definiți o pensulă Din punctul de vedere al GDI, desenul cu un stilou geometric este o formă sofisticată de umplere a zonei Funcția WidenPath permite unei aplicații să obțină date de traseu care vor fi folosite de GDI pentru a desena linii geometrice Cu toate acestea, Microsoft nu explică nicăieri de ce o aplicație ar putea avea nevoie de aceste date interne Amintiți-vă ce s-a spus mai sus - doar transformările afine sunt acceptate în GDI; nu există suport direct pentru transformările non-afine (cum ar fi transformările de perspectivă în , și puncte) O caracteristică distinctivă a liniilor geometrice este prezența unei grosimi vizibile Pe de altă parte, o linie geometrică trasată are o grosime constantă Imaginea D ar trebui să imite Capitolul efect de perspectivă, astfel încât obiectele îndepărtate, inclusiv liniile geometrice, ar trebui să scadă în dimensiune Caracteristica WidenPath oferă „diviziunea muncii” necesară între GDI și aplicații O aplicație poate primi datele traseului după aplicarea WidenPath, poate aplica o transformare în perspectivă sau orice altă transformare care modifică grosimea liniei și poate returna calea rezultată pentru periere Ca rezultat, veți obține linii cu grosime variabilă Următorul fragment definește o clasă abstractă pentru efectuarea transformărilor bidimensionale K DMap și o clasă derivată Kі LinearMap care mapează o fereastră dreptunghiulară la un patrulater arbitrar Metoda K DMap: :Map mapează punctele individuale la date legate de traiectorie clasa K DMap { public: Mapdong virtual și px long&py) = : }: clasa KBiLinearMap : K DMap public { dublu xOO, yOO, xOl yOl, xlO ylO xll, yll: orgx dublu, orgie, lățime, înălțime: public: void SetWindowdnt x, int y, int w, int h) { orgx=x: orgie=y:width=w; inaltime=h; } void SetDest nation(P INT P[J) { xOO = P[O] x; yOO = P[O] y: xOl = P[l] x; yOl = P[l] y: xlO = P[ ] x: ylO = P[ ] y: xll = P[ ] x: yll = P[ ] y: } Mapdong virtual și px, long și py) { x dublu = (px - orgx ) / lățime: dublu y = (py - orgie) / înălțime: px = (lung) ( (lx) * ( xOO * ( -y) + xOl * y ) + x * ( xlO * ( -y) + xll * y) ): py = (lung) ( (lx) * ( yOO * ( -y) + yOl * y ) + x * ( ylO * ( -y) + yll * y) ): Traiectorii Operații grafice folosind trasee de scule Desenarea directă a traiectoriei este realizată de mai multe funcții: StrokePath, Fi Path și StrokeAndFi Path Funcția StrokePath desenează linii și curbe în cadrul traseului curent folosind creionul curent și limita de unghi a contextului dispozitivului Din punct de vedere conceptual, StrokePath este echivalent cu obținerea datelor de cale cu funcția GetPath și apelarea funcției PolyDraw - liniile desenate vor fi aceleași Principala diferență este că GetPath și PolyDraw nu schimbă căile contextului dispozitivului, în timp ce funcția StrokePath le eliberează după cursă Prin urmare, după apelarea StrokePath, aplicația trebuie să construiască o nouă cale dacă are nevoie de una Există o soluție - apelați funcția SaveDC înainte de a apela StrokePath și RestoreDC după aceasta Doar o pereche de funcții împiedică distrugerea obiectului traiectoriei Nu este recomandat să apelați StrokePath după apelarea WidenPath cu același stilou geometric gros Dacă creionul gros folosit pentru a extinde calea este lăsat selectat în context, calea originală va fi desenată cu un stilou cu lățime dublă, rezultând goluri urâte și bucle mai mari Când utilizați un stilou subțire, buclele urâte generate de funcția WidenPath devin clar vizibile (ca în partea stângă a Figura ) Iată un mic fragment care utilizează funcția WidenPath pentru a lărgi traseele cu pene geometrice foarte groase și apoi apelează funcția StrokePath cu un stilou cosmetic subțire pentru a trasa traseele generate de funcția WidenPath: pentru (int = : GetLength(m step): în timp ce ( curlen >" lungime ) { dublu xl = m xl; dublu yl = m yl; m xl += (x -m xl) * lungime / curlen; m yl +s (y -mj/ ) * lungime / curlen; Dacă ( ! m pDash->DrawDash(xl, yl, m xl, m yl, m step) ) returnează FALSE; curl -= lungime; m step++; lungime = m pDash->GetLength(m step); } returnează TRUE; } BOOL KStyleCurve::PolyDraw(const POINT *ppt const BYTE *pbTypes int nCount) Exemplu: Desenarea liniilor de stil personalizate { int lastmovex = ; int lastmovey = : pentru (Int = : pixuri simple și avansate, linii, curbe Bezier, arce, trasee de instrumente și stiluri personalizate personalizate descrise în secțiunea „Exemplu: Desenarea liniilor de stil personalizate” Capitolul Zone închise La originile matematicii moderne se află două probleme matematice vechi - găsirea unei tangente la o curbă dată și calcularea ariei din interiorul unei curbe închise date Prima problemă este rezolvată în domeniul calculului diferențial, iar a doua - în domeniul integralei O anumită analogie poate fi urmărită în interfața grafică Windows API - unele funcții aliniază pixelii de-a lungul liniilor și curbelor, în timp ce altele umplu forme închise formate din linii și curbe De la liniile și curbele unidimensionale detaliate în capitolul , trecem la o nouă dimensiune și trecem la umplerea zonelor Acest capitol acoperă principalele subiecte legate de umpluturi - pensule; structurile de date de bază ale pensulei; dreptunghiuri și regiuni; principalele tipuri de forme geometrice (dreptunghiuri, poligoane, elipse, sectoare și segmente) și o tendință la modă precum umpluturile cu gradient perii În procesul de umplere a unei zone trebuie luați în considerare mulți factori: forma geometrică, regulile de interpretare a acesteia, operațiile raster, modul de umplere a fundalului, culoarea și modelul În API-ul Windows, informațiile despre culoare și model utilizate pentru a umple zonele sunt grupate într-un obiect pensulă Destul de ciudat, desenul cu o pensulă în Windows este mai ușor decât cu un pix, deoarece pixurile desenează linii și curbe cu greutăți și stiluri diferite, în timp ce pensulele nu au această capacitate Culoarea pensulei determină culoarea de bază a pixelilor atunci când pictați forme închise, în timp ce modelul creează o varietate de efecte de umplere repetate obiect perie boolean Există mai multe funcții în GDI pentru a crea obiecte pensulă sau, pentru a fi mai precis, obiecte pensulă logice Peria logică descrie cerințele Capitolul valorile aplicate umplerii de către aplicație (în primul rând culoare și model) Îi spune driverului de dispozitiv cum ar trebui să arate umplerea, dar driverele de dispozitiv lucrează cu diferite structuri de date denumite în mod obișnuit „perii fizice” pentru a reprezenta propria interpretare a periei Structurile de date interne ale unei pensule logice sunt gestionate de GDI, la fel ca și structurile de date ale altor obiecte (contexte de dispozitiv, pixuri logice, fonturi logice și așa mai departe) După ce o perie logică este creată, mânerul acesteia este returnat în aplicație și utilizat la referințele ulterioare la perie Mânerele obiectelor GDI sunt descrise de tipul generic HGDIOBJ; tipul HBRUSH este rezervat manipulatorilor de pensule logice Fiecare context de dispozitiv are asociat un atribut perie logic, care este accesat folosind funcțiile GetCurrentObject, SelectObject, GetObject și EnumObjects Aceste funcții, discutate în Capitolul cu privire la obiectele stilou, efectuează aceleași operații pe diferite tipuri de obiecte GDI Un obiect perie logică, ca orice alt obiect GDI, consumă procesele utilizatorului și resursele kernelului și, de asemenea, ocupă cel puțin o intrare în tabelul de obiecte GDI, așa că periile logice inutile ar trebui șterse cu funcția DeleteObject Perii standard GDI definește mai multe obiecte pensule standard care pot fi utilizate cu ușurință de orice aplicație Pentru a obține o perie standard, apelați funcția GetStockObject cu una dintre constantele BLACK BRUSH, DKGRAYJRUSH, GRAY BRUSH, LTGRAY BRUSH, WHITE BRUSH, NULLBRUSH (la fel ca HOLLOW BRUSH) sau DC BRUSH Pensulele standard Negru, Gri închis, Gri, Gri deschis și Alb sunt perii uniforme cu diferite niveluri de intensitate de gri În mod implicit, o perie albă este selectată în contextul dispozitivului Când este selectată o perie standard goală (NULL BRUSH sau HOLLOW BRUSH), interiorul zonei nu este pictat peste (în mod similar cu un stilou gol nu desenează linii) Deoarece funcția GetStockObject operează pe obiecte GDI generice, rezultatul apelării acesteia pe obiecte pensulă standard este de obicei convertit la tipul HBRUSH Peria DC standard returnată de apelul GetStockObject(DC BRUSH) este una dintre noile caracteristici din Windows / Pensulele DC, precum pixurile DC, sunt pseudo-obiecte GDI și își pot schimba culoarea atunci când sunt selectate într-un context de dispozitiv Pentru a lucra cu culoarea unei pensule DC selectată în contextul dispozitivului, utilizați următoarele funcții: COLORREF GetDCBrushColorCHDC hDC): COLORREF SetDCBrushColor(HDC hDC COLORREF crColor); Funcția GetDCBrushColor returnează culoarea curentă a pensulei DC; funcția Set-DCPenColor atribuie o nouă culoare și returnează culoarea veche Aceste funcții pot fi folosite chiar dacă peria DC nu este selectată în contextul dispozitivului, dar în acest caz nu afectează nimic Obiectele standard sunt pre-create de sistemul de operare și partajate de toate procesele care rulează pe sistem După terminare perii lucrând cu obiecte standard, manipulatorii lor nu trebuie șterși Cu toate acestea, apelarea DeleteObject pe un mâner de perie standard este complet sigură - funcția pur și simplu returnează TRUE fără a face nimic Perii personalizate Este puțin probabil ca cineva să fie mulțumit de o imagine pictată cu doar cinci nuanțe de gri Pentru a crea sau a obține pensule personalizate multicolore cu modele interesante, utilizați următoarele funcții: HBRUSH CreateSol dBrush(COLORREF crColor); HBRUSH CreateHatchBrushdnt fnStyle, COLORREF crRef): HBRUSH CreatePatternBrushCHBITMAP hbmp): HBRUSH CreateDIBPatternBrushPt(CONST VOID * IpPackedDIB, UINT lUsage); HBRUSH CreateDIBPatternBrushCHGLOBAL hglbDIBPacked UINT fuColorSpec): HBRUSH GetSysColorBrushdnt nlndex); Perii uniforme Cel mai simplu mod de a crea pensule uniforme este de a specifica o culoare Funcția CreateSol idBrush creează doar o perie logică Atunci când un mâner de perie este selectat într-un context de dispozitiv, GDI și driverul de dispozitiv trebuie să convină asupra implementării periei Dacă contextul dispozitivului nu utilizează o paletă, specificatorul de culoare este ușor convertit în componente RGB Pe de altă parte, pentru contextele care utilizează o paletă, specificatorul de culoare trebuie convertit într-un index de paletă Dacă se găsește o potrivire, indexul găsit este utilizat în rezultat; în caz contrar, dispozitivul simulează pixelii culorii dorite combinând culorile disponibile prin ceea ce este cunoscut sub numele de dithering Dithering-ul vă permite să reproduceți culori complementare pe adaptoare video cu și de culori și chiar să simulați ieșirea în tonuri de gri pe imprimante alb-negru Următorul fragment arată cum să creați o perie uniformă și să o selectați în contextul dispozitivului Programul desenează un dreptunghi de x din fiecare dintre cele de culori, de la albastru la alb și afișează imagini mărite ale dreptunghiurilor de culori dispuse pe o linie diagonală Dacă rulați programul în modul video de de culori, veți vedea modelele de amestecare prezentate în Fig // Dreptunghi neconturat Se ectObject(hDC, GetStockObject(NULL PEN)); pentru (Int y= ; y î X* bcWidth: helght = ((BITMAPCOREHEADER *) hGlobal)->bcHeight: } pauză: cazul : { HRSRC hResource = F ndResource(hCards, MAKEINTRES URCE( - ) RT BITMAP); HGLOBAL hGlobal = LoadResource(hCards, hResource): hBrush = CreateDIBPatternBrush(hGlobal DIB RGB COLORS); lățime = ((BITMAPCOREHEADER *) hGlobal)->bcWidth: helght = ((BITMAPCOREHEADER *) hGlobal)->bcHeight: Capitolul } HGDIOBJ hold = SelectObject(hDC, hBrush); PUNCTUL P = { * + + w dth* / + înălțime* / }; LPtoDP(hDC, &P ); SetBrushOrgEx(hDC Px, Py, NULL): // Aliniați imaginile hărții // într-un dreptunghi Dreptunghi (hDC * + , , * + +l a* / + +helgh* / +l): SelectObject(hDC, Hold): DeleteObject(hBrush); } Programul parcurge trei cazuri posibile În primul caz, regele de pică este încărcat ca un bitmap DDB, din care este creată o perie bitmap În al doilea caz, Regina Inimilor este încărcată și memorată; indicatorul rezultat către bitmap-ul DIB împachetat este folosit pentru a crea pensula DIB bitmap În al treilea caz, jack of diamonds este încărcat și transferat în memorie pentru a obține mânerul de bloc necesar la crearea unei alte pensule bitmap DIB Pensulele create oferă pictura a trei dreptunghiuri, ale căror dimensiuni sunt de aproximativ , ori dimensiunea cărților de pe fiecare parte Pentru a ne asigura că rasterele sunt aliniate cu colțul din stânga sus al dreptunghiului, folosim funcția LPtoDP pentru a mapa coordonatele logice la coordonatele dispozitivului și apelăm funcția SetBrushOrg, care face alinierea directă Rezultatul este prezentat în fig Rețineți că pe Windows / cards dll este un DLL pe biți și nu poate fi încărcat direct de aplicațiile Win Există câteva lucruri de reținut atunci când lucrați cu pensule bitmap În primul rând, la nivelul GDI, periile bitmap nu oferă un înlocuitor complet pentru periile de contur Pentru o perie bitmap, fiecare pixel este interpretat ca un pixel de culoare de bază; pixelii de fundal nu există perii În al doilea rând, dimensiunea pensulelor bitmap, la fel ca dimensiunea pensulelor de contur, este specificată în unitățile de coordonate ale dispozitivului Modelele desenate cu pensule bitmap au întotdeauna aceeași orientare și dimensiune în sistemul de coordonate al dispozitivului Pentru a crea modele care se potrivesc cu rezoluția dispozitivului, o aplicație trebuie să folosească mai multe hărți de biți diferite Dar a treia problemă este cea mai gravă: pe platformele din afara familiei NT, dimensiunea maximă a periei bitmap este limitată la x pixeli De exemplu, dacă încercați să utilizați un bitmap mare în Windows / , va fi afișat doar colțul din stânga sus Următorul capitol descrie soluții pentru a obține efectul dorit folosind funcțiile raster GDI Pensiile cu modele bitmap sunt adesea folosite pentru a desena linii punctate orizontale și verticale Amintiți-vă de ultimul capitol - în liniile pseudo-punctate PS DOT, un punct este reprezentat de trei pixeli, iar stilul punctat PS ALTERNATE real este acceptat doar în familia NT Dacă nu aveți chef să desenați o linie punctată pixel cu pixel, există o soluție ușoară - folosiți o perie bitmap O aplicație poate crea o perie de șah și poate desena dreptunghiuri cu o lățime sau înălțime de un pixel, sau să picteze zone care sunt tăiate la o lățime sau înălțime de un pixel Fragmentul de mai jos creează o perie de șah care este folosită pentru a trasa conturul unui dreptunghi, imitând stilul PS ALTERNATE Modelul este generat pe baza unui bitmap alb-negru de x creat de funcția CreateBitmap Pentru a desena linii cu grosimea de un pixel, se folosește funcția PatBlt, care funcționează în modul de afișare MM TEXT În alte moduri de afișare sau în modul grafic avansat, decuparea este necesară pentru a se asigura că linia trasată are o grosime de un pixel Acest fragment ilustrează, de asemenea, a doua utilizare comună a pensulei de șah, pictând modele translucide Să presupunem că contextul actual al dispozitivului are culoarea textului negru, culoarea fundalului alb, pixelul este negru (RGBCO, , )) și pixelul este alb (RGBC , , )) Culoarea pensulei este combinată cu culoarea destinației folosind operația bitmap R MASKPEN Astfel, pixelii negri ai pensulei rămân negri, iar pixelii albi nu modifică conținutul destinației La umbrire, jumătate din pixelii receptorului sunt întunecați și apare un efect „translucid” void Frame (HDC hDC, int xO int yO, int xl int yl) { Tabla de șah scurtă nesemnată[] = { OxAA x OxAA x , OxAA x OxAA x }; HBITMAP hBitmap = CreateBitmap( , Chessboard); HBRUSH hBrush = CreatePatternBrush(hBitmap); DeleteObject(hBitmap); HGDIOBJ hold = SelectObject(hDC hBrush); // Dreptunghi PS ALTERNATE PatBltChDC xO yO xl-xO PATCOPIE); PatBltChDC, xO yl xl-xO PATCOPY): Capitolul PatBlt(hDC xO, yO, yl-yO PATCOPY); PatBlt(hDC, x , yO, , yl-yO PATCOPY); int vechi = SetR P (hDC, R MASKPEN); DreptunghiChDC, xO+ , yO+ , xl- , yl- ): SetR P (hDC, vechi): SelectObject(hDC, hold); DeleteObject(hBrush); } Pe fig arată efectul aplicării unui model de șah Poate că dezvoltatorii de la Microsoft ar fi trebuit să includă acest model în pensulele ■ □ pro-rollaging otic economic economicfficated otic economice precoce economice nucleu C cream Woxes Crow Curving otic economicationoticoticoticiationoticiationore /ital coreital c cream Woodmon □ venituri din otic economic economic economice timpurie oscis □ venituri otice economice economice economice lemn otic economice lemn otic economic economic economic I'sood oticexograf otic timpuriu timpuriu precoceoticventriotic □□□□□□□□□□□□□□□□□□□□ □□□□□■□■□■□■■■■■■■■■■■■■■■■■■■■■ □□□□□■□■□■■■□■□««■□■□■□■□■□și Orez Aplicarea unui model de tablă de șah: linii punctate și semi-transparență Pensule de culoare ale sistemului Sistemul de gestionare a ferestrelor folosește zeci de culori concepute pentru a afișa diverse părți ale ferestrei - bare de titlu, cadre, meniuri, bare de defilare, butoane etc Aceste culori se numesc culori de sistem și sunt configurate într-o aplicație specială din panoul de control sau la program nivel, folosind funcțiile API GetSysColor și SetSysColor Pentru fiecare culoare de sistem, sistemul creează o perie standard Aplicațiile pot obține pensule de culoare ale sistemului utilizând funcția GetSysColorBrush, transmițându-i valori care variază de la COLOR-SCROLLBAR până la C L RJ RADIENTACTIVECAPTION Pensulele de culoare ale sistemului sunt folosite pentru a picta zone ale căror culori ar trebui să se potrivească cu zonele pictate de sistem Dacă fereastra în sine controlează redarea zonei non-client, pensulele de culoare ale sistemului sunt extrem de utile Aceste pensule se numără printre obiectele GDI standard care nu trebuie să fie șterse după utilizare Apelurile la funcția DeleteObject pentru pensulele de culoare ale sistemului sunt ignorate perii Pensiile de culoare ale sistemului pot fi specificate ca pensule de fundal atunci când se înregistrează clase de ferestre, în timp ce utilizarea indicilor de culoare ale sistemului în formatul (HBRUSH) (FERASTRĂ COLOR + ) este permisă Potrivit MSDN, pe unele sisteme, apelul la GetSystemColorBrush poate eșua dacă user dll este încărcat și descărcat în mod repetat Acest lucru se datorează faptului că de fiecare dată când user dll este încărcat, sistemul creează pensule pentru culorile sistemului, dar uită să le ștergă la descărcare Astfel, după ce biblioteca user dll este încărcată și descărcată de câteva sute de ori, tabelul de obiecte GDI se poate depăși Astfel de situații apar doar în aplicațiile de consolă care efectuează încărcarea/descărcarea dinamică a DLL-urilor, în special user dll În aplicațiile GUI, user dll este întotdeauna încărcat, nu este niciodată descărcat sau reîncărcat În Windows NT/ , pensulele de culoare ale sistemului sunt create o singură dată și partajate de toate procesele Structura LOGBRUSH Să rezumăm pe scurt cele spuse mai sus Pensulele sunt concepute pentru vopsirea zonelor din interior Trei tipuri de perii sunt acceptate în GDI: uniformă, cursă și model O pensulă uniformă este definită de un specificator de culoare care poate folosi amestecarea atunci când este implementată pe dispozitive cu palete O caracteristică a pensulelor de contur este împărțirea pixelilor în principal și fundal; acestea din urmă sunt afișate numai în modul de umplere a fundalului OPAC Pensulele de contur sunt folosite doar pentru imagini simple de pe ecran, deoarece modelele lor de obicei nu se scalează pentru a se potrivi cu rezoluția și scara dispozitivului O perie de model este definită pe baza unei hărți de biți dependente de dispozitiv sau independent de dispozitiv În procesul de umplere, rasterul este plasat în mod repetat în limitele zonei conform principiului mozaicului În implementarea GDI pentru Windows / , dimensiunea maximă a părții utilizate a rasterului este de x pixeli, ceea ce reduce semnificativ utilitatea acestei caracteristici utile Toate cele trei tipuri de pensule sunt descrise de structura LOGBRUSH, care poate fi transmisă funcției CreateBrushIndirect când se creează o pensulă logică Definițiile relevante sunt date mai jos typedef struct tagLOGBRUSH { UINTIbStyle: COLORREFIbColor: LONG IbHatch; }; HBRUSH CreateBrushIndirectCCONST LOGBRRUSH * Iplb): Principalele dificultăți la lucrul cu structura LOGBRUSH sunt legate de faptul că la alegerea stilului BS PATTERN, câmpul IbHatch conține manipulatorul DDB, iar pentru stilurile BS DIBPATTERN și BS DIBPATTERNPT, acest câmp specifică manipulatorul sau pointerul blocului DIB și valoarea LOWORD(lbColor) este egal cu DIB PAL COLORS sau DIB RGB COLORS Structura LOGBRUSH poate fi folosită pentru a prelua informații despre un obiect pensulă GDI folosind funcția GetObject: LOGBRUSH logbrush: GetObject(hBrush s zeof(LOGBRUSH) și logbrush): Capitolul Nu vă așteptați să găsiți un mâner sau un indicator valid către un bitmap cu pensulă de model în structura LOGBRUSH returnată de GetObject Când creați o perie de model, GDI creează o copie a bitmap-ului într-o structură internă de date care este ascunsă de aplicațiile utilizatorului Structura LOGBRUSH este folosită și la crearea pixurilor extinse Când desenați linii și curbe cu un creion geometric, utilizați de fapt o pensulă, astfel încât amestecarea, hașurarea și hărțile de biți pot fi, de asemenea, necesare aici Obiectul perie logică este gestionat de GDI În Windows NT/ , obiectul pensulă logică constă dintr-o componentă în modul utilizator care optimizează procesul de creare și distrugere frecventă a pensulelor uniforme și o componentă în modul kernel care stochează informații complete despre pensula logică În special, obiectul în modul kernel conține date despre culorile de prim-plan și de fundal, un set extins de steaguri de stil, un bitmap, o mască și așa mai departe Masca este necesară pentru a implementa pensule de contur care păstrează imaginea de fundal La nivel DDI, motorul grafic permite driverului de dispozitiv să furnizeze propriile hărți de biți pentru a implementa pensule de contur la nivelul dispozitivului grafic, astfel încât modelul de contur să fie mai bine distins Există un punct de intrare special prin care driverul dispozitivului implementează o perie logică - cu alte cuvinte, își creează propria interpretare internă a periei logice, care este folosită ulterior în operațiunile grafice folosind pensula logică Periile logice (cu excepția pensulelor cu model) ocupă foarte puțină memorie Pentru pensulele de model, un mâner suplimentar este creat în tabelul GDI (atât pentru periile de model DDB, cât și pentru DIB) și este alocată memorie pentru a stoca o copie a bitmap-ului dreptunghiuri Figura geometrică principală din API-ul Windows este un dreptunghi Dreptunghiurile sunt folosite pentru a defini ferestrele și zonele client, diferite forme cu o casetă de delimitare dreptunghiulară, formatarea textului și chiar decuparea Win definește o structură de date și un API pentru tratarea dreptunghiurilor ca structuri de date și pentru diferite umbriri ale zonelor dreptunghiulare Dreptunghi ca structură de date În API-ul Win , dreptunghiurile sunt definite folosind structura RECT, pentru care sunt definite aproximativ o duzină de operațiuni diferite typedef struct RECT { LONG stânga; top LUNG; LONG dreapta: Fund lung; dreptunghiuri BOOL SetRect(LPRECT Iprc Int xStânga Int ySus int xDreapta, int yBottom): BOOL SetRectEmpty(LPRECT IPrc); BOOL IsRectEmpty(CONST RECT * IPrc): BOOL EqualRect(CONST RECT *lprcl CONST RECT *lprc ): BOOL CopyRect(LPRECT IprcDst, CONST RECT * IprcSrc): BOOL OffsetRect(LPRECT IPrc, int dx, int dy): BOOL PtInRect(CONST RECT * Iprc POINT pt); BOOL InflateRect(CONST LPRECT IPrc, int dx int dy): BOOL IntersectRect(CONST LPRECT IprcDst, CONST RECT * IprcSrcl CONST RECT *lprcSrc ): BOOL SubtractRect(LPRECT lprcDst CONST RECT * IprcSrcl CONST RECT *lprcSrc ): BOOL UnionRect(LPRECT IprcDst CONST RECT *lprcSrcl, CONST RECT *lprcSrc ): Dreptunghiul este definit de coordonatele minime și maxime din ambele axe, care corespund colțurilor din stânga sus și din dreapta jos în sistemul de coordonate al dispozitivului Când lucrați cu funcții care folosesc structura RECT, se presupune întotdeauna că coordonatele din stânga nu sunt mai mari decât dreapta, iar partea de sus nu este mai mare decât cea de jos Acest lucru se datorează faptului că aceste funcții sunt acceptate de managerul de ferestre pentru a efectua operațiuni pe dreptunghiuri de fereastră și zona client specificate în coordonatele ecranului Înainte de a transmite date acestor funcții, aplicația trebuie să le normalizeze, altfel rezultatele pot fi destul de neașteptate Se presupune, de asemenea, corectitudinea pointerilor transmise către RECT - verificarea pointerilor în implementările curente este foarte limitată (probabil din motive de viteză) Funcția SetRect populează toate cele patru câmpuri ale unei structuri RECT cu valori noi și este utilizată în principal pentru a inițializa dreptunghiuri noi Funcția SetRectEmpty setează toate cele patru câmpuri la zero, rezultând un dreptunghi gol Funcția IsRectEmpty testează dacă dreptunghiul dat este gol (adică înălțimea sau lățimea sa este zero sau o valoare negativă) Funcția Equal Rect verifică dacă două dreptunghiuri conțin margini care se potrivesc în perechi Funcția CopyRect copiază dreptunghiul original în structura dată Funcția OfffsetRect deplasează dreptunghiul (adică adaugă dx la coordonatele sale stânga și dreapta și dy la coordonatele sale de sus și de jos) Funcția PtlnRect verifică dacă un punct aparține unui dreptunghi; părțile de sus și stânga ale dreptunghiului sunt incluse în verificare, dar părțile din dreapta și de jos nu sunt Cu alte cuvinte, punctele situate pe laturile din stânga și de sus sunt considerate ca aparținând dreptunghiului, în timp ce punctele din partea dreaptă și de jos nu sunt incluse în dreptunghi Funcția InflateRect extinde un dreptunghi cu unități dx pe orizontală și cu unități dy pe verticală (pe fiecare parte) Dacă este setat la valori negative, dreptunghiul se micșorează Funcția IntersectRect calculează aria de intersecție a două dreptunghiuri (se obține fie un dreptunghi, fie o zonă goală) Funcția SubtractRect scade un dreptunghi dintr-un alt dreptunghi Toată lumea știe că în cazul general, cu o astfel de excepție, se generează o zonă non-dreptunghiulară, care este descrisă de trei dreptunghiuri În API-ul Win , rezultatul unui apel la SubtractRect este determinat de bounding rect Capitolul mogon Astfel, dacă aria de suprapunere a dreptunghiurilor A și B este aceeași lățime sau înălțime ca și dreptunghiul A, este exclusă din rezultatul A-B; în caz contrar, dreptunghiul A rămâne neschimbat Funcția UnionRect returnează dreptunghiul de delimitare al unei zone ale cărei puncte aparțin cel puțin unuia dintre cele două dreptunghiuri Când lucrați cu RECT, toate aceste funcții sunt implementate foarte simplu Pentru cerințele critice de performanță, o aplicație le poate implementa ca cod inline (ipiiine) în loc să apeleze funcții Win API De exemplu, apelarea SetRect cu cinci parametri necesită un minim de cinci instrucțiuni, în timp ce utilizarea codului inline se poate descurca cu doar patru instrucțiuni Formatul unei structuri RECT din memorie se potrivește exact cu cel al unui tablou de două structuri POINT La transformarea coordonatelor cu funcțiile LPtoDP sau DPtoLP, o structură RECT poate fi transmisă în loc de o matrice de două structuri POINT Dar dacă transformări sau mapări sunt aplicate structurii RECT, trebuie să aveți grijă suplimentară pentru a vă asigura că dreptunghiul rămâne normalizat și paralel cu axele Desen dreptunghiuri API-ul Win oferă mai multe funcții care pictează interiorul unui dreptunghi cu o pensulă, îi mângâie contururile cu un stilou sau ambele: BOOL Dreptunghi (HDC hDC int nLeftRect int nTopRect, int nRightRect int nBottomRect): int Fi Rect(HDC hDC, CONST RECT * Iprc, HBRUSH hbr): int FrameRect(HDC hDC CONST RECT * Iprc HBRUSH hbr): BOOL InvertRect(HDC hDC, CONST RECT * IPrc): BOOL DrawFocusRect(HDC hDC CONST RECT * IPrc): Dreptunghi Funcția Rectangle desenează un dreptunghi definit de patru coordonate Un număr destul de mare de atribute de context afectează procesul de desen Deoarece funcția dreptunghi este una dintre funcțiile de bază GDI, o vom analiza mai detaliat Figura ilustrează rezultatul aplicării funcției Rectangle pe diferite atribute de context de dispozitiv Când contextul este într-un mod grafic compatibil, părțile din dreapta și de jos ale dreptunghiului din sistemul de coordonate al dispozitivului nu sunt desenate (urmând regulile tradiționale de includere/excludere laturi) Rețineți că partea dreaptă a dreptunghiului poate să nu se potrivească cu nBottomRect; este determinat de valoarea maximă a lui nTopRect și nBottomRect atunci când este mapat la sistemul de coordonate al dispozitivului Dar dacă contextul dispozitivului este în modul grafic avansat, toate cele patru laturi ale dreptunghiului sunt redate, așa cum se arată în figura de jos din coloana din stânga Această modificare este probabil inevitabilă, deoarece capacitatea de a aplica transformări afine arbitrare în modul avansat face mai dificilă determinarea părților din dreapta și de jos (comparativ cu partea de sus și de jos) Perimetrul dreptunghiului este conturat de obiectul stilou curent selectat în contextul dispozitivului dreptunghiuri Dacă grosimea stiloului este de un pixel în coordonatele dispozitivului, sunt desenați doar pixelii perimetrului Dacă creionul are n pixeli lățime, un pixel este desenat pe linia centrală, (n- )/ pixeli sunt desenați în afara dreptunghiului și alți (n- )/ pixeli sunt desenați în interiorul dreptunghiului Când utilizați un creion cu stilul PS INSIDEFRAME, un pixel este desenat pe linia centrală și (n- ) mai mulți pixeli sunt desenați în interiorul dreptunghiului Un alt caz special este stiloul gol, care nu urmărește perimetrul dreptunghiului Când utilizați un stilou gol, lățimea și înălțimea dreptunghiului sunt reduse cu un pixel Pix albastru, R NOTCOPYPEN Stilo negru, mod avansat Creion cu o grosime de pixeli, desenând în interiorul căii Orez Diferite stiluri de dreptunghiuri Obiectul pensulă curent pictează zona care nu a fost pictată cu stiloul, iar în cazul unui stilou gol, întregul dreptunghi, redus cu un pixel Rezultatele aplicării unei pensule sunt, de asemenea, afectate de modul de umplere a fundalului, de culoarea de fundal și de punctul de bază al pensulei Operația de bitmap curentă în contextul dispozitivului se aplică atât perimetrului, cât și interiorului dreptunghiului De exemplu, dacă selectați operația R N P, funcția dreptunghi nu face nimic FILIRect Funcția FilIRect pictează cu o pensulă un dreptunghi definit de o structură RECT Laturile din dreapta și de jos din sistemul de coordonate al dispozitivului sunt întotdeauna excluse, chiar și în modul grafic avansat Spre deosebire de apelarea Rectangle cu un stilou gol, care are ca rezultat desenarea unui dreptunghi mai mic, funcția FilIRect umple întregul dreptunghi Nu utilizează atributul de operare bitmap binar în contextul dispozitivului Parametrul pensulă transmis către FilIRect poate conține și indexul culorii sistemului în format (HBRUSH)(index + ) Diferențele dintre FilIRect și Rectangle Capitolul se explică prin faptul că implementarea Fi Rect utilizează instrumente GDI pentru a lucra cu rasterele Fi Rect apelează funcția nedocumentată PolyPatBlt GDI, care se bazează pe apelarea PatBlt (vezi capitolul următor) FrameRect Funcția FrameRect pictează perimetrul unui dreptunghi cu o perie (nu un stilou!) În acest caz, conturul imaginii desenate are aceleași dimensiuni ca la apelarea Fi Rect Grosimea perimetrului este o unitate logică, iar grosimea sa reală în pixeli este determinată de transformarea lumii și modul de afișare Desenarea perimetrului unui dreptunghi vă permite să creați efecte interesante care sunt greu de realizat cu un stilou GDI În special, pensula vă permite să utilizați culori mixte fără a crea un stilou geometric sau să desenați trasee dreptunghiulare punctate cu drepturi depline cu o perie de biți din șah Funcția FrameRect este, de asemenea, implementată folosind funcția PolyPatBlt nedocumentată InvertRect Funcția InvertRect inversează culoarea fiecărui pixel dintr-un dreptunghi, similar cu modul în care un stilou în modul R N T inversează pixelii dintr-o linie În dispozitivele cu paletă, indicii paletei sunt inversați, iar culoarea este determinată de locația culorilor în paletă În dispozitivele fără paletă, negrul devine alb, albul devine negru și valoarea RGB a fiecărui pixel este inversată Apelarea InvertRect de două ori cu aceiași parametri restabilește conținutul original al contextului dispozitivului Funcția InvertRect este implementată de funcția PatBlt, deci urmează aceleași reguli de includere/excludere laterale ca și funcțiile FrameRect și Fi AND Rect DrawFocusRect Funcția DrawFocusRect este similară cu funcția FrameRect Ea desenează perimetrul unui dreptunghi cu o pensulă cu model de șah folosind o operație raster XOR Ca și în cazul funcției InvertRect, apelarea DrawFocusRect restaurează din nou conținutul original al contextului dispozitivului Funcția DrawFocusRect este implementată de funcția PolyPatBlt cu o perie de model și o operație raster XOR Numele DrawFocusRect provine de la utilizarea acestei funcții în modulul de ferestre De exemplu, în casetele de dialog, funcția DrawFocusRect desenează un contur dreptunghi punctat pe un buton care primește focalizarea tastaturii Când focalizarea se mută pe alt buton, dreptunghiul este șters apelând din nou DrawFocusRect, după care este apelată funcția de a desena dreptunghiul pe butonul care a primit focalizarea Funcția DrawFocusRect poate fi folosită și pentru a desena dreptunghiuri flexibile Când utilizați această caracteristică într-o interacțiune interactivă, asigurați-vă că definițiile dreptunghiului sunt corecte MSDN exagerează problema și avertizează programatorii că dreptunghiurile desenate cu funcția DrawFocusRect nu pot fi derulate De fapt, nu există probleme cu derularea: regiunea actualizată dreptunghiuri conține numai zone deschise recent după derulare, deci apelarea DrawFocusRect în timpul procesării unui mesaj WM PAINT nu șterge dreptunghiul Dar dacă contextul dispozitivului a fost obținut printr-o funcție GetDC care nu setează regiunea sistemului, este mai ușor să ștergi dreptunghiul înainte de a derula Pe fig arată rezultatul apelării funcțiilor Fi Rect, FrameRect, InvertRect și DrawFocusRect, care nu sunt funcții GDI, deși folosesc funcții GDI în munca lor Aceste funcții sunt suportate și specifice sistemului de ferestre (user dll) Orez Funcții de desen dreptunghiular utilizate de sistemul de ferestre Desenarea granițelor și controalelor API-ul Win include o serie de funcții pe care sistemul de ferestre le folosește pentru a desena o varietate de chenare și controale care sunt direct legate de desenarea dreptunghiurilor Aceste funcții pot fi utilizate la implementarea elementelor redate de proprietar, randarea personalizată a unei zone non-client sau simularea aspectului ferestrelor și controalelor Mai jos sunt prototipurile pentru cele mai importante două funcții, DrawEdge și DrawFrameControl BOOL DrawEdge(HDC hDC, LPRECT IPrc, UINT edge UINT grFlags); BOOL DrawFrameControl(HDC hDC LPRECT IPrc, UINT uType UINT uState); Ambele funcții primesc un handle de context, o structură RECT care descrie zona de desenat și două steaguri Indicatoarele și semnificația lor sunt descrise în documentația MSDN și vom oferi doar exemple de utilizare a acestora Următorul fragment arată cum să desenați diferite margini (Figura ) pentru (int e= : e = ) SetPolyF Mode(hDC ALTERNATE); el se SetPolyFi lMode(hDC WINDING); swltch ( t % ) { cazul : FiHPath(hDC); pauză; cazul ; StrokeAndFi Path(hDC); pauză; cazul : WidePath(hDC); FI Path(hDC): break; cazul : WidePath(hDC); { KGDIObject thin(hDC CreatePen(PS SOLID, RGB( OxFF))); StrokeAndFi HPath(hDC); } ) SetV newportOrgEx(hDC NULL); ) Regiuni În capitolul , am aruncat o privire amplă asupra regiunilor, concentrându-ne pe utilizarea lor în decupare În Win GDI, regiunile sunt importante nu numai ca structuri de date, ci și ca rezultat Această secțiune detaliază regiunile și principalele lor domenii de aplicare Cele mai importante utilizări ale regiunilor în programarea Windows sunt enumerate mai jos (dintre care unele au fost deja menționate în Capitolul ) Regiuni O definiție a formei ferestrei: SetWindowRgn О Stocarea informațiilor despre zonele ferestrei care trebuie redesenate: Irivali dateRgn, GetllpdateRgn O Decupare: SelectClipRgn, SetMetaRgn A Ieșire grafică: regiunea poate fi afișată direct pe ecran O verificare de apartenență: regiunile pot fi folosite pentru a reprezenta forme geometrice Despre DirectDraw: Structura datelor regiunii este utilizată de interfața IDirect-Clipper Din punct de vedere GDI, o regiune definește o colecție de puncte într-un spațiu de coordonate Această colecție poate fi goală sau poate ocupa întreg spațiul de coordonate; au o formă dreptunghiulară sau orice formă neregulată Obiectul regiune este gestionat de GDI și reprezintă o regiune din sistem Ca și în cazul altor obiecte GDI, odată ce un obiect regiune este creat, aplicația primește doar mânerul său, care poate fi transmis către GDI atunci când face referire la acel obiect Manipularile de regiune în GDI sunt de tip HRGN Structura internă de date care reprezintă obiectul regiune este destul de complexă și poate fi destul de mare Când obiectul regiune devine inutil, acesta ar trebui să fie șters cu funcția DeleteObject Crearea unui obiect regiune La crearea de noi obiecte de regiune, sunt utilizate următoarele funcții: HRGN CreateRectRgndnt nLeftRect, int nTopRect, int nRightRect, int nBottomRect); HRGN CreateRectRgnIndirect(CONST RECT * IPrc); HRGN CreateRoundRectRgnCint nLeftRect,int nTopRect, int nRightRect, int nBottomRect, int nWidthEl ipse, int nHeightElipse); HRGN CreateEl ipticRgn(int nLeftRect, int nTopRect, int nRightRect int nBottomRect); HRGN CreateEl ipticRgnlndirect(CONST RECT * IPrc); HRGN CreatePolygonRgn(CONST POINT * Ippt, int cPoints, int fnPolyFi Mode); HRGN CreatePolyPolygonRgn(CONST POINT * Ippt, CONST INT * IpPolyCounts, int nCount int fnPolyFi Mode): HRGN PathToRegion(HDC hDC); Toate funcțiile din acest grup, cu excepția PathToRegion, sunt independente de contextul dispozitivului, creionul sau pensula Obiectul regiune este un obiect independent care reprezintă o figură geometrică Într-un alt context, coordonatele regiunii sunt interpretate ca coordonate logice sau de dispozitiv Funcția CreateRectRgn creează o regiune care conține toate punctele unei regiuni dreptunghiulare, care este de obicei definită de colțurile din stânga sus și din dreapta jos Cele două puncte care definesc un dreptunghi nu trebuie să fie ordonate corect; GDI le normalizează conform regulilor de reprezentare internă GDI (coordonată stânga mai mică decât dreapta, coordonata superioară Capitolul mai puțin decât partea de jos) Funcția CreateRectRgnIndirect este o versiune simplificată a CreateRectRgn care primește parametrii printr-o structură RECT Pe Windows NT/ , implementarea CreateRectRgnIndirect este un simplu apel la CreateRectRgn Când utilizați un obiect de regiune dreptunghiulară, acesta este întotdeauna interpretat prin regula excluderii părților inferioare și drepte Această regulă se aplică atât modurilor grafice compatibile, cât și celor avansate De exemplu, apelarea CreateRectRgn( , , , ) creează o regiune goală (în loc de o regiune care conține un singur punct ( , )) În sistemul de coordonate al dispozitivului, apelarea CreateRectRgn( , , , ) creează o regiune care conține un singur punct ( , ), iar în acest sens este echivalent cu apelarea CreateRectRgnd, , , ) Funcția CreateRoundRectRgn( , , , ) creează o regiune formată din toate punctele dintr-un dreptunghi rotunjit Fiecare dintre cele patru colțuri corespunde unui sfert din elipsa nWidthElipsexnHeightElipse Dintr-un motiv necunoscut, atunci când o regiune este creată ca dreptunghi rotunjit, părțile sale de jos și din dreapta sunt excluse din structura internă de date care reprezintă regiunea Rețineți că situația este diferită de o regiune dreptunghiulară, în care părțile de jos și din dreapta sunt incluse în reprezentarea internă Astfel, atunci când utilizați un dreptunghi rotunjit într-un context de dispozitiv, două rânduri de pixeli sunt excluse în partea dreaptă și inferioară Când este utilizat într-un sistem de coordonate logic, lățimea marginilor excluse este o unitate logică plus o unitate de dispozitiv Funcția CreateEl ipticRgn creează o regiune constând din toate punctele interioare ale unei elipse Funcția CreateEllipticRgnlndirect este o versiune simplificată care redirecționează apelul către această funcție La fel ca CreateRoundRectRgn, funcția CreateEl ipticRgn exclude părțile de jos și din dreapta din reprezentarea internă a regiunii Astfel, atunci când se utilizează o regiune eliptică, părțile din dreapta și de jos sunt excluse de două ori Există un articol în baza de cunoștințe Microsoft care abordează problema excluderii partidelor atunci când lucrați cu funcția CreateEl ipticRgn (Q ) Se spune că funcția El lipse include colțul din dreapta jos al casetei de delimitare în calcule, iar funcția CreateEl ipticRgn exclude acest punct Cu toate acestea, declarațiile bazei de cunoștințe Microsoft diferă de la practică Din fig Figura - arată că atunci când Ellipse este apelată în modul grafic compatibil, părțile din dreapta și de jos sunt, de asemenea, excluse După cum se arată în fig , funcția CreateEl ipticRgn în modul grafic compatibil exclude întotdeauna o unitate logică în plus decât funcția El lipse Pe fig Figura prezintă un dreptunghi, un dreptunghi rotunjit și o elipsă Desenul vă permite să studiați structura lor la nivelul pixelilor individuali Aceste trei forme de bază au fost desenate în mai multe moduri - apeluri directe GDI API, crearea și desenarea unei regiuni, conversia unei regiuni într-o cale și conversia unei căi într-o regiune Toate metodele au fost testate atât în modurile grafice compatibile, cât și în cele avansate Din figură, puteți vedea că în modul compatibil, funcțiile Dreptunghi, El lipse și RoundRectangle exclud părțile din dreapta și de jos, în timp ce în modul avansat, aceste laturi sunt incluse în calcule Funcția CreateRectRgn exclude întotdeauna Regiuni părțile din dreapta și de jos, iar funcțiile CreateRoundRectRgn și CreateEl ipticRgn le exclud de două ori Cu toate acestea, nu reiese clar din figură că forma desenată de funcția CreateEllipticRgn este ușor diferită ca formă de elipsa desenată de funcția El lipse, chiar dacă luăm în considerare corecția și mărim dimensiunea acesteia cu una Dacă aveți nevoie de precizie de % (de exemplu, dacă regiunea creată este necesară pentru a trunchia rezultatul unui apel Ellipse), Microsoft recomandă utilizarea funcției de regiune Apel direct al funcțiilor API GDI Crearea și afișarea unei regiuni Transformarea unei regiuni într-o traiectorie Transformarea unei traiectorii într-o regiune Orez Funcțiile CreateRectRgn, CreateRoundRectRgn și CreateEllipticRgn Funcția CreatePolygonRgn creează o regiune constând din toate punctele interioare ale poligonului După cum sa menționat în secțiunea „Poligoane”, întrebarea dacă un punct aparține unui poligon este decisă ținând cont de modul actual de umplere a poligonului Pentru a face funcția CreatePolygonRgn independentă de contextul dispozitivului, modul de umplere îi este transmis în ultimul parametru Ambele funcții includ toate coordonatele din reprezentările lor interne ale regiunilor, cu toate acestea, când umbriți o regiune, părțile din dreapta și de jos sunt excluse Prin urmare, aria regiunii create prin apelarea CreatePolygonRgn este mai mică decât aria dreptunghiului creat de funcția Polygon cu aceiași parametri Funcția finală de creare a regiunii, PathToRegion, convertește traiectoria curentă a contextului dispozitivului într-o regiune Un obiect calea uneltei diferă de alte obiecte GDI prin faptul că rămâne întotdeauna asociat cu un anumit context de dispozitiv la nivelul API-ului GDI, astfel încât GDI are capacitatea de a stoca obiecte calea instrumentelor în coordonatele dispozitivului, mai degrabă decât în coordonatele logice Funcția PathToRegion închide toate formele de traseu deschise și le convertește într-o regiune în funcție de modul curent de umplere a poligonului selectat în contextul dispozitivului Regiunea generată utilizează sistemul de coordonate al dispozitivului din contextul dat, spre deosebire de funcția GetPath, care necesită o transformare inversă pentru a traduce datele traiectoriei din coordonatele dispozitivului în coordonate logice Deși funcția PathToRegion folosește toate coordonatele originale atunci când construiește o regiune, procesul de utilizare a unei regiuni exclude părțile din dreapta și de jos Să rezumam Există trei motive pentru diferențele în zona regiunii și cifra desenată de funcția GDI corespunzătoare În primul rând, funcțiile CreateRectRgn, CreateRectRgnIndirect, CreatePolygonRgn, CreatePolyPolygonRgn Capitolul și PathToRgn folosesc coordonatele originale pentru a construi reprezentarea internă a regiunii, în timp ce funcțiile CreateRoundRectRgn, CreateEl ipticRgn și CreateEllipticRgnIndirect decrementează coordonatele laturilor drepte și inferioare ale dreptunghiului de delimitare cu una Această împrejurare ar trebui considerată probabil un defect de implementare, și nu o decizie arhitecturală conștientă În al doilea rând, atunci când utilizați o regiune într-un context de dispozitiv (fie în scopuri de tăiere, fie atunci când desenați), părțile din dreapta și de jos sunt întotdeauna excluse În al treilea rând, funcțiile de creare a regiunii se comportă la fel în ambele moduri grafice, iar funcțiile dreptunghi, elipsă și dreptunghi rotunjit includ părțile din dreapta și de jos în modul grafic avansat Operații cu obiecte ale regiunilor O regiune este un set de puncte dintr-un spațiu bidimensional, astfel încât definirea operațiilor pe mulțimi pentru obiectele regiunilor pare destul de naturală GDI oferă o gamă bogată de funcții pentru preluarea informațiilor, mutarea, transformarea, resetarea și îmbinarea regiunilor Prototipurile acestor funcții sunt prezentate mai jos BOOL PtInRegion(HRGN hrgn, int X, int Y); BOOL RectInRegion(HRGN hrgn, CONST RECT * Iprc): BOOL EqualRgn(HRGN hSrcRgnl, HRGN hSrcRgn ); Int GetRgnBox(HRGN hrgn, LPRECT Iprc); int CombineRgnCHRGN hrgnDest, HRGN hrgnSrcl, hrgnSrc , int fnCombineMode); int OffsetRgnCHRGN hrgn,int nXOffset, int nYOffset): DWORD GetRegionData(HRGN hRgn, DWORD dwCount, LPRGNDATA IpRgnData): HRGN ExtCreateRegion(CONST XFORM * IpXForm, DWORD nCount, CONST RGNDATA * IpRgnData); Obținerea de informații despre o regiune Funcția PtlnRegion verifică dacă un punct (x, y) aparține mulțimii de puncte dintr-o regiune Se crede că părțile drepte și inferioare ale regiunii nu îi aparțin De exemplu, pentru o regiune goală creată prin apelarea CreateRectRgn( , , , ), funcția PtlnRegion returnează întotdeauna FALSE; pentru o regiune cu un singur punct creată prin apelarea CreateRectRgn(O,O,l,l), PtlnRegion returnează TRUE numai pentru punctul ( , ) Funcția PtlnRegion este extrem de utilă atunci când implementați tipuri exotice de butoane sau regiuni pe care se poate face clic care își schimbă culoarea sub cursorul mouse-ului (indicând că un clic pe acea regiune este gestionat într-un mod special) Aplicația trebuie doar să creeze un obiect regiune corespunzător regiunii pe care se poate face clic și să apeleze funcția PtlnRegion atunci când procesează mesajul WM MOUSEMOVE pentru a schimba imaginea Acțiuni similare ar trebui incluse în procesarea mesajelor mouse-ului pentru a detecta un clic în interiorul zonei pe care se poate face clic Regiuni Listarea arată clasa KButton pentru lucrul cu butoane pe care se poate face clic, precum și două clase derivate pentru lucrul cu butoane dreptunghiulare și eliptice Funcția DefineButton definește dreptunghiul de delimitare al butonului Funcția virtuală DrawButton creează un obiect regiune și desenează un buton în funcție de dacă a fost făcut clic pe acesta Funcția IsOnButton folosește PtlnRegion pentru a verifica dacă punctul (x, y) se află în interiorul butonului Funcția UpdateButton actualizează imaginea butonului în funcție de poziția curentă a cursorului mouse-ului Lista Clasa KButton clasa KButton { protejat: HRGN m hReg on: bool m bOn; int m x m a, m w m h; public: KButton() { m hRegion = NULL: m bOn = fals; } virtual -KButtonO {} void DefineButton(int x int y int w int h) { m x = x; m y=y: m w=w; m h = h: }' Buton de desenare virtual void (HDC hDC) {} vold UpdateButton (HDC hDC LPARAM xy) { dacă ( m bOn != IsOnButton(xy) ) { m bOn = ! m bOn: DrawButton(hDC); } } bool IsOnButton(LPARAM xy) const { returnează PtInRegion(m hRegion LOWORD(xy), HIWORD(xy)) != : }b Continuare Capitolul Lista Continuare clasa KRectButton : KButton public { public: void DrawButton (HDC hDC) { RECT rect = { m x, m y m x+m w, m y+mji }; if ( m hRegion == NULL ) m hRegion = CreateRectRgnIndirect(& rect); InflateRect(&rect , ); Fi Rect(hDC & rect GetSysColorBrush(COLOR BTNFACE)); InflateRect(&rect - , - ); DrawFrameControl(hDC &rect DFC CAPTION, DFCS CAPTIONHELP | (m bOn ? : DFCSJNACTIVE)); } }: clasa KEllipseButton : KButton public { public c: void DrawButton (HDC hDC) { RECT rect = { m x m y, m x+m w m y+m h}; if ( mJiRegion == NULL ) m hRegion = CreateEllipticRgnlndirect(& rect); dacă ( m bOn ) { FillRgn(hDC, mJiRegion, GetSysColorBrush(COLOR CAPTIONTEXT)); FrameRgn(hDC mJiRegion, GetSysColorBrush(COLOR ACTIVEBORDER) ); } el se Fi Rgn(hDC mJiRegion GetSysColorBrush(COLOR INACTIVECAPTIONTEXT)); FrameRgn(hDC, mJiRegion, GetSysColorBrush(COLOR INACTIVEBORDER) ); } } }: Codul pentru următorul fragment afișează o zonă de client cu două butoane pe care se poate face clic care își schimbă culoarea când treceți cu mouse-ul peste Dacă faceți clic pe oricare dintre aceste butoane, pe ecran va apărea o casetă de mesaj LRESULT KMyCanvas::WndProc(HWND hWnd UINT uMsg WPARAM wParam LPARAMIParam) { comutator (uMsg) Regiuni { caz WM CREATE: rbtn DefineButtondO , ): ebtn DefineButtondO ): întoarcere : caz WM PAINT: { PAINTSTRUCT ps: HDC hDC = BeginPaint(m hWnd &ps); rbtn DrawButton(hDC): ebtn DrawButton(hDC): EndPaint(m hWnd &ps): } returnează : caz WM MOUSEMOVE: { HDC hDC = GetDC(hWnd): rbtn,UpdateButton(hDC IParam); ebtn UpdateButton(hDC IParam); ReleaseDC(hWnd hDC): } returnează : caz WMJ BUTTONDOWN: if ( rbtn IsOnButton(IParam) ) MessageBox(hWnd „Butonul dreptunghic sa făcut clic” NULL MB OK); if ( ebtn IsOnButton(IParam) ) MessageBox(hWnd „Elipse Button Clicked” NULL MB OK); returnează : Mod implicit: Ir = DefWindowProc(hWnd uMsg wParam IParam): } unu O altă funcție, RectlnRegion, verifică dacă vreunul dintre punctele din dreptunghi specificat de parametrul Ircc (cu excepția părților din dreapta și de jos) aparțin regiunii specificate Rețineți că funcția nu verifică dacă întregul dreptunghi se află în interiorul regiunii Poate că ar trebui redenumit RectTouchRegion Funcția EqualRegion compară două regiuni și verifică dacă acestea conțin aceleași seturi de puncte Dacă aceiași manipulatori sunt trecuți în doi parametri, regiunile sunt, fără îndoială, aceleași Dar chiar și manipulatori diferiți pot corespunde acelorași seturi de puncte De exemplu, apelurile la CreateRectRgn( , , , ) și CreateRectRgnd, , , ) creează regiuni goale care sunt egale în ceea ce privește funcția Equal Rect Prin prezența funcției EqualRegion, se poate face o presupunere rezonabilă că obiectele regiunilor au o reprezentare internă unică, adică exact o reprezentare corespunde fiecărui set de puncte În caz contrar, funcția EqualRegion ar fi foarte lentă Capitolul Funcția GetRgnBox returnează caseta de delimitare a regiunii Pentru un set de puncte gol, căsuța de delimitare este întotdeauna definită de cvartetul { , , , } Pentru alte regiuni dreptunghiulare, caseta de delimitare este dreptunghiul original al regiunii, normalizat astfel încât stânga să fie mai mică decât dreapta și sus să fie mai mică decât jos După cum sa menționat mai sus, pentru regiunile dreptunghiulare eliptice sau rotunjite, GDI elimină o unitate din partea dreaptă și de jos, astfel încât caseta de delimitare este mai mică decât dreptunghiul specificat la definirea regiunii De exemplu, CreateEl lipticRgn( , , , ) returnează o regiune cu o casetă de delimitare de { , , , } Caseta de delimitare a unei regiuni poate fi utilizată pentru a determina rapid dacă un punct individual sau orice puncte din regiune aparțin unei anumite regiuni; acest lucru este deosebit de important pentru cerințele critice de performanță Dreptunghiul returnat de funcția GetRgnBox permite unei aplicații să efectueze o verificare rapidă fără a utiliza funcțiile GDI sau a trece de la modul utilizator la modul kernel Dreptunghiul rcPaint din structura PAINTSTRUCT completată de funcția BeginPaint conține datele dreptunghiului de delimitare pentru regiunea de sistem a ferestrei Acest dreptunghi este folosit de multe aplicații pentru a determina dacă anumite obiecte trebuie redesenate atunci când procesează un mesaj WM-PAINT Setați operațiuni Funcția CombineRgn vă permite să efectuați câteva operații utile asupra obiectelor regiune, împrumutate din teoria mulțimilor Funcția primește trei obiecte regiune hrgnDest, hrgnSrcl și hrgnSrc , precum și un parametru întreg fnCombineMode Când se apelează CombineRgn, parametrul hrgnDest trebuie să conțină mânerul unui obiect de regiune valid Funcția înlocuiește obiectul regiune reprezentat de acest manipulator cu obiectul generat atunci când funcția a fost apelată Parametrul fnCombi neMode specifică operația care trebuie efectuată pe regiunile hrgnSrcl și hrgnSrc - copiere, intersectare, îmbinare, scădere sau diferență simetrică Operațiunile de regiune care oferă cinci moduri diferite de combinare a regiunilor au fost enumerate în Capitolul (vezi Tabelul ), iar o reprezentare grafică a acestor operații este prezentată în Figura Două regiuni RGN AND RGN OR RGN XOR RGN DIFF RGN COPY Orez Operațiuni cu regiuni Regiuni Funcțiile GetRgnBox și CombineRgn returnează un cod de complexitate întreg pentru regiunea generată sau un cod de eroare Rezultatele posibile sunt enumerate în tabel Tabelul Rezultatele apelurilor la funcțiile GetRgnBox și CombineRgn Descriere constantă NULLREGION Regiunea goală SIMPLERGION Regiunea definită de un singur dreptunghi COMPLEXREGION Regiunea definită de mai multe dreptunghiuri EROARE Eroare - Valori ale parametrilor nevalide sau memorie insuficientă Regiunea nu a fost creată Dacă o regiune este un set de puncte, cum ar trebui să arate mulțimea universală (adică mulțimea care conține toate punctele posibile)? În Win GDI, coordonatele logice sunt specificate ca numere întregi pe de biți, în timp ce coordonatele dispozitivului pe sistemele din familia NT sunt specificate ca numere întregi nenegative pe de biți Pe sistemele din afara familiei NT, coordonatele sunt trunchiate la numere întregi de biți Prin urmare, setul universal pentru regiuni trebuie definit de căsuța de delimitare [ x , x , x FFFFFFF, x FFFFFFF] Cu toate acestea, pe sistemele din familia NT, GDI pare să trunchieze aceste numere la numere întregi de de biți, astfel încât caseta de delimitare a mulțimii universale este redusă la [-—( " ),—( " ),( " )— ,( " >— ] Se aplică o altă limitare nedocumentată: atunci când se utilizează funcții de regiune, valorile coordonatelor logice sunt limitate la numere întregi semnate pe de biți în loc de numere întregi semnate pe de biți Operațiile de set sunt foarte utile în calculele geometrice Dacă doriți să știți dacă două căi închise se suprapun, le puteți converti în poligoane cu funcția FlattenPath și puteți implementa singur algoritmul de verificare a suprapunerii poligoanelor, dar nu este atât de ușor de făcut Există o altă soluție: convertiți traiectoriile în regiuni și calculați intersecțiile lor folosind funcția CombineRgn(RGN AND) Dacă intersecția nu este goală, atunci cele două traiectorii originale se intersectează Astfel de verificări sunt adesea întâlnite în programarea jocurilor, unde contactul a două obiecte este de obicei însoțit de una sau alta acțiune Folosind operațiunile de setare, puteți determina cu ușurință dacă o regiune este cuprinsă în altă regiune S-a spus deja mai sus că funcția RectlnRegion verifică doar faptul contactului, adică prezența punctelor comune între dreptunghi și regiune Funcția de mai jos verifică dacă un dreptunghi este conținut într-o regiune Pentru a face acest lucru, calculează uniunea dreptunghiului cu regiunea folosind funcția CombineRgn și apoi, folosind funcția Equal Rgn, verifică dacă regiunea combinată se potrivește cu cea inițială BOOL RectContalnedInRegion(HRGN hrgn CONST RECT * Iprc) { HRGN hComblne = CreateRectRgnIndirect(Iprc); Capitolul Comb neRgn(hComblne, hrgn, hComblne, RGN OR); BOOL rslt = EqualRgn(hCombine, hrgn); DeleteObject(hComblne); return rslt; } Transformări de date din regiune GDI acceptă traducerea, oglindirea și transformările de scalare între sistemul de coordonate a paginii și sistemul de coordonate al dispozitivului Pe sistemele din familia NT, interfața GDI acceptă transformări afine mai generale între spațiile de coordonate ale lumii și ale paginii, permițând rotația și translația Toate aceste transformări sunt acceptate și pentru obiectele regiune cu o limitare logică - rotațiile și translațiile sunt suportate direct numai în sistemele din familia NT Funcția OffsetRgn oferă cea mai simplă transformare, offset Preia valorile offset-ului chi-y, le adaugă la toate coordonatele obiectului regiune și returnează codul de complexitate al regiunii Funcția OffsetRgn poate fi folosită pentru a desena în mod repetat obiecte pe suprafața dispozitivului (desenând regiunea în sine sau aplicând-o pentru tăiere) O aplicație poate folosi regiunea, o poate muta în altă locație cu funcția OffsetRgn și o poate folosi din nou De asemenea, puteți utiliza această funcție pentru a urmări obiectele în mișcare într-un joc sau animație Dacă, de exemplu, regiunea descrie contururile unei mașini de curse, atunci pe măsură ce mașina se mișcă, regiunea utilizată pentru detectarea coliziunilor ar trebui să se miște și ea Transformări mai generale sunt efectuate de două funcții: GetRegionData și ExtCreateRegion Funcția GetRegionData convertește structura de date internă a regiunii într-o structură RGNDATA care poate fi utilizată într-un program Funcția ExtCreateRegion preia structuri RGNDATA și XFORM (definiție a transformării afine), transformă datele și creează o nouă regiune Structura esențială RGNDATA este definită după cum urmează: typedef struct RGNDATAHEADER DWORD dwSize; // DWORD IType; // DWORD nCount; // DWORD nRgnSize; // RECT rcBounds; // }RGNHEADER; { sizeof(RGNDATAHEADER) RDH-RECTANGURI numărul de dreptunghiuri din dimensiunea memoriei tampon de regiune cu dreptunghiul de delimitare a datelor de regiune typedef struct RGNDATA { RGNDATAHEADERrdh; char BufferEU: // dimensiune variabilă }RGNDATA; Când vă familiarizați cu structura RGNDATA, ar trebui să acordați atenție unor circumstanțe interesante În primul rând, RGNDATA nu este o structură de date internă folosită pentru a reprezenta regiuni în GDI În sistemele din familia NT, regiunile sunt reprezentate de o structură de date mai eficientă - o matrice dinamică REGIONOBJ care conține o matrice de structuri SCAN Structura- Regiuni pa SCAN descrie „linia de scanare a unei regiuni”, adică intersecția unei regiuni cu o zonă delimitată de două linii orizontale, cu condiția ca intersecția conturului regiunii cu această zonă să fie formată doar din segmente verticale Structura SCAN stochează o matrice de coordonate x ale acestor segmente, iar numărul de elemente ale matricei este întotdeauna par Nu există dovezi care să susțină că regiunile sunt reprezentate de forme trapezoidale, așa cum se menționează în documentația Microsoft Descrierea regiunii printr-o matrice de structuri SCAN permite stocarea doar a coordonatei x pentru fiecare intersecție, deoarece acestea au aceleași coordonate; economisind astfel memorie În plus, ordonarea matricei de structuri SCAN de sus în jos și de la stânga la dreapta oferă o reprezentare fără ambiguitate a regiunilor și operațiuni eficiente cu acestea De exemplu, când se combină mai multe regiuni mici într-o singură regiune mare folosind funcția CombineRgn, reprezentarea internă a regiunii rezultate nu ar trebui să depindă de ordinea în care regiunile sunt combinate Pentru detalii, vedeți „WinDbg și extensia GDI Debugger” în Capitolul Pe sistemele din afara familiei NT, coordonatele pe biți sunt folosite în loc de coordonatele pe de biți Cantitatea de memorie ocupată de structura REGIONOBJ depinde de complexitatea regiunii Să presupunem că o regiune este împărțită în N linii de scanare și numărul mediu de intersecții pe linie este M Înălțimea minimă a liniei de scanare este una, dar poate fi de mai multe unități Volumul structurii REGIONOBJ este calculat prin formula: slzeof(REGIONOBJ) = ( *M + )*(N+ )+ Pentru o regiune dreptunghiulară, o linie de scanare ocupă întregul dreptunghi, deci N == , M = ; dimensiunea structurii este de numai octeți GDI poate stoca doar o casetă de delimitare și un steag special care indică faptul că aceasta este o regiune simplă Pentru o regiune eliptică, numărul de linii de scanare se apropie de / din înălțimea elipsei, M = Când se creează o regiune pentru o elipsă de pagină completă pe o imprimantă de dpi, N = / x ȘI x = , slzeof(REGIONOBJ) = KB Datorită regiunilor, aplicația poate implementa chei de culoare; pentru a face acest lucru, regiunea este creată pe baza tuturor pixelilor din raster a căror culoare diferă de cheia de culoare Această regiune este folosită pentru decupare la afișarea unui raster, drept urmare toți pixelii a căror culoare se potrivește cu culoarea cheii nu sunt afișați În cel mai rău caz, N este egal cu înălțimea rasterului, M este jumătate din lățimea rasterului, iar structura REGIONOBJ conține octeți pentru fiecare pixel Dacă aplicația dvs este intensă în regiune, aveți în vedere costul memoriei În realitate, motorul grafic alocă mai multă memorie decât este necesar pentru a reprezenta regiunea; excesul este destinat unei posibile mariri a dimensiunii rasterului O strategie similară este utilizată atunci când lucrați cu matrice dinamice pentru a minimiza suprasarcina de alocare a memoriei dinamice și copiere a datelor Structura REGIONOBJ este de fapt bidimensională; prima dimensiune este o matrice de structuri SCAN sortate după coordonatele y crescătoare, iar a doua dimensiune este o matrice ordonată de coordonate x Această arhitectură asigură o performanță acceptabilă a operațiunilor cu regiuni Capitolul Să presupunem că doriți să știți dacă un punct aparține unei regiuni Dacă un punct trece testul căsuței de delimitare, coordonatele sale y pot fi comparate cu coordonatele y a fiecărei structuri SCAN folosind o căutare liniară Dimensiunea structurii SCAN este stocată la începutul și la sfârșitul acesteia, ceea ce face mult mai ușor să treceți la următoarea structură După găsirea structurii SCAN dorite, următoarea căutare liniară este efectuată de-a lungul coordonatei x Astfel, timpul de execuție al lui PtlnRegion are ordinul (N) + (M) Algoritmul optim care utilizează căutarea binară oferă ordinea (log(N)) + (log(M)), dar aceasta necesită complexitatea structurii datelor GDI încearcă să utilizeze structuri de date mici legate de pointer ori de câte ori este posibil pentru a minimiza alocarea dinamică a memoriei Funcția CombineRgn pentru combinarea, intersectarea și scăderea regiunilor are o complexitate similară în ceea ce privește numărul de comparații necesare Cu toate acestea, copierea datelor într-o nouă regiune necesită timp suplimentar Astfel, atunci când n regiuni sunt combinate prin funcția CombineRgn, în cel mai rău caz, complexitatea este de ordinul lui O(r ), adică odată cu dublarea numărului de regiuni, costurile de timp cresc de patru ori Astfel de algoritmi ar trebui evitati ori de câte ori este posibil Structura RGNDATA oferă o interfață comună pentru lucrul cu regiuni din aplicațiile Win care rulează pe diferite platforme În plus, structura RGNDATA este utilizată de interfața IDirectDrawCl ipper DirectDraw Această structură conține un antet de dimensiune fixă cu informații despre dimensiunea regiunii, tipul și caseta de delimitare și o serie de structuri RECT În RGNDATA, reprezentarea internă bidimensională a unei regiuni în GDI este convertită într-o structură de date unidimensională Pentru a reprezenta o regiune cu N linii de scanare și un număr mediu de intersecții pe linie egal cu M, sunt necesare M/ x N dreptunghiuri Costul total al memoriei este calculat folosind următoarea formulă: sizeof(RGNDATA) = * M * N + Pentru o regiune formată dintr-o singură formă convexă (de exemplu, un dreptunghi, o elipsă sau un dreptunghi rotunjit), M = , deci structura RGNDATA ocupă aproximativ / din volumul REGIONOBJ Pentru valorile mari ale lui M, dimensiunea structurii RGNDATA este aproape de două ori mai mare decât a REGIONOBJ Structura RGNDATA (ca și structura REGIONOBJ) este generată de GDI și elementele sale sunt întotdeauna într-o anumită ordine Structurile sale RECT sunt ordonate de la stânga la dreapta, de sus în jos Toate structurile RECT sunt normalizate, adică stânga este mai mică decât dreapta și sus este mai puțin decât jos Deoarece structura RGNDATA este o matrice liniară de dreptunghiuri, o aplicație poate accelera unii algoritmi De exemplu, verificarea dacă un dreptunghi cu o regiune reprezentată printr-o structură RGNDATA are puncte comune se poate face folosind o căutare binară într-o matrice în loc de una liniară, ceea ce reduce complexitatea la ( og (M x N)) Pe de altă parte, setați operațiunile folosind CombineRgn copiați datele, în timp ce costul de timp este legat liniar de cantitatea de date Funcția GetRegionData scrie o structură RGNDATA într-un buffer furnizat de aplicație Cu toate acestea, înainte de a apela GetRegionData, dimensiunea exactă a structurii Regiuni excursiile sunt de obicei necunoscute aplicației O strategie posibilă este următoarea: aplicația ia dimensiunea RGNDATA, care este potrivită pentru % din cazuri, alocă un buffer de dimensiunea corespunzătoare (probabil pe stivă) și apelează funcția GetRegionData, trecându-i dimensiunea tampon și un indicator către acesta Dacă tamponul este suficient de mare, acesta este umplut cu o structură RGNDATA, a cărei dimensiune exactă este returnată de funcție Dacă tamponul este prea mic, funcția GetRegionData returnează și tamponul nu este umplut În acest caz, aplicația apelează GetRegionData, trecând pentru parametrul dwCount și NULL pentru parametrul IpRgnData; GDI returnează dimensiunea necesară a tamponului Aplicația alocă memorie (de obicei din heap) și apelează din nou GetRegionData, trimițând dimensiunea exactă a bufferului și un pointer către acesta Desigur, aplicația poate renunța la primul apel și poate apela imediat GetRegionData pentru a obține dimensiunea bufferului Pe fig Figura arată cum arată structura RGNDATA pentru regiuni ca dreptunghi, dreptunghi rotunjit, elipsă și triunghi; toate aceste regiuni au aceeași casetă de delimitare { , , , } O regiune dreptunghiulară constă dintr-un singur dreptunghi; Regiunea dreptunghi rotunjită conține dreptunghiuri, în principal pentru colțurile rotunjite; regiunea eliptică conține dreptunghiuri, în timp ce regiunea triunghiulară are până la dreptunghiuri Dreptunghiurile de delimitare RGNDATA din figură sunt conturate cu un stilou negru, iar dreptunghiurile matricei RECT sunt colorate alternativ în gri închis și gri deschis CreateRectRgn: ( , , , ) rcBound: ( , , , ) nNumăr: CreateRoundRectRdn: ( , , , , , ) rcBound: ( , , , ) nCount: CreateEllipticRgn: ( , , , ) rcBound: ( , , , ) nNumăr: CreatePolygonRgn: ( , , , , , ) rcBound: ( , , , ) nCount: Dimensiune: octeți Dimensiune: octeți Dimensiune: de octeți Dimensiune: octeți Orez Structura RGNDATA pentru diferite tipuri de regiuni Funcția ExtCreateRegion vă permite să creați un obiect regiune bazat pe o structură RGNDATA cu capacitatea de a aplica o transformare afină datelor regiunii Structura RGNDATA poate fi fie obținută direct din GDI folosind funcția GetRegionData, fie generată în aplicație Când este apelată ExtCreateRegion, toate structurile RECT trebuie normalizate, iar câmpul rcBounds al structurii RGNDATA trebuie să conțină un dreptunghi comun de delimitare În caz contrar, încercarea de apel va eșua sau regiunea va fi generată incorect Capitolul Primul parametru al funcției ExtCreateRegion conține un pointer către matricea de transformare afină (pe sistemele din afara familiei NT, transformarea nu poate include deplasări și rotații) Transformările regiunii sunt foarte des necesare în aplicații De exemplu, regiunea returnată de funcția PathToRegion este definită în sistemul de coordonate al dispozitivului Dacă o regiune este utilizată direct pentru desen și nu pentru tăiere, aplicația trebuie să o convertească într-un sistem de coordonate logic Pentru cel mai simplu offset, funcția OffsetRgn este suficientă, dar pentru transformări mai generale, ar trebui folosită funcția ExtCreateRegion Structura RGNDATA reprezintă regiunea în coordonate întregi; curbele sunt aproximate prin segmente, ca atunci când apelați FlattenPath pe o cale de instrumente În consecință, „jaggies” apar adesea la scalare Dacă regiunea poate fi definită ca o cale, transformarea căii și apoi mutarea în regiune va oferi un rezultat mai precis Funcția ExtCreateRegion pe sistemele de familie non-NT nu poate gestiona mai mult de de dreptunghiuri simultan O soluție este să împărțiți structura mare RGNDATA în câteva mai mici, să apelați ExtCreateRegion pe fiecare structură și apoi să combinați rezultatele cu funcția Combi neRgn Lista arată o clasă simplă pentru lucrul cu funcțiile GetRegion-Data și ExtCreateRegion Lista Clasa KRegion: lucrul cu datele regiunii clasa KRegiune { public: int m nRegionSize: nu mjiRectCount: RECT * m pRect: RGNDATA * m pRegion: KRegiune() { mjRegionSize= : mjiRectCount = : m pRegion = NULL: m pRect = NULL: void Resetare(void) { if ( m pRegion ) șterge [] (char *) m pRegion; m pRegion = NULL; mjiRegionSize = : mjiRectCount = : m pRect = NULL; } -KRegiuneO Regiuni { ResetO: } BOOL GetRegionData(HRGN hRgn): HRGN CreateRegion(XFORM * pXForm); }: BOOL KReglon::GetRegionData(HRGN hRgn) { resetO; m nRegionSize = ::GetRegionData(hRgn, , NULL): if ( m nRegionSize== ) returnează FALSE: m pRegion = (RGNDATA *) new char[m nRegionSize]; if ( m pRegion==NULL ) returnează FALSE: ::GetRegi onData(hRgn, mjiRegionSize, m pRegi on): m nRectCount = m pRegion->rdh nCount; m pRect = (RECT *) & m pRegion->Buffer; returnează TRUE: } HRGN KRegion::CreateRegion(XFORM * pXForm) { return ExtCreateRegion(pXForm, m nRegionSize m pRegion); } Funcțiile GetRegionData și ExtCreateRegion permit aplicațiilor să construiască și să transforme ele însele structuri RGNDATA și să le transmită la GDI pentru a crea regiuni Această caracteristică poate fi utilă pentru implementarea rotațiilor sau schimbărilor într-un sistem din afara familiei NT, sau pentru a depăși costul nedorit O(n ) al combinării n regiuni cu funcția CombineRgn Desenarea regiunilor GDI oferă mai multe funcții pentru desenarea zonei ocupate de o regiune cu un anumit manipulator: BOOL FillRgn(HDC hDC, HRGN hrgn HBRUSH hbr); BOOL PaintRgn(HDC hDC HRGN hrgn); BOOL FrameRgn(HDC hDC HRGN hrgn HBRUSH hbr int nWidth int nHeight); BOOL InvertRgn(HDC hDC HRGN hrgn): Toate aceste funcții primesc un handle de context de dispozitiv și un handle de regiune Coordonatele regiunii sunt specificate într-un sistem de coordonate logic, Capitolul și nu în sistemul de coordonate al dispozitivului, cum ar fi coordonatele regiunii de tăiere Prin urmare, nu puteți trece direct mânerul de regiune returnat de funcția PathToRegion acestor funcții (cu excepția cazului în care coordonatele logice sunt identice cu coordonatele dispozitivului sau dacă acționați în mod deliberat) Motorul grafic convertește obiectul regiune în coordonatele dispozitivului, excluzând părțile din dreapta și de jos Funcția FillRgn pictează o regiune cu pensula specificată de parametrul hbr Funcția PaintRgn face același lucru, dar folosește pensula curentă a contextului dispozitivului GDI folosește aceeași implementare pentru aceste două funcții Funcția FrameRgn mângâie conturul regiunii cu o perie a cărei lățime și înălțime sunt determinate atunci când funcția este apelată Acest lucru vă permite să creați contururi de grosime variabilă; cu un stilou obișnuit, care desenează întotdeauna linii de grosime constantă, acest lucru nu este posibil Funcția FrameRgn își interpretează „pen-ul” ca un dreptunghi paralel cu axele, cu toate ieșirile având loc numai în regiune și niciodată în afara acesteia Funcția InvertRgn inversează pixelii framebuffer-ului dispozitivului în același mod în care se folosește operația bitmap R N T Prin principiul de funcționare, seamănă cu funcția InvertRect Primele trei funcții, FillRgn, PaintRgn și FrameRgn, utilizează operația curentă de bitmap binar și respectă modul curent de umplere a fundalului Funcția InvertRgn inversează întreaga regiune cu operația R N T Pe fig Figura - arată cum aceste funcții transformă un dreptunghi rotunjit desenat de funcția RoundRect RoundRect FillRgn FrameRgnfl l ) FrameRgn[ , ) Orez Funcțiile PaintRgn, FillRgn, FrameRgn și InvertRgn La prima vedere, funcțiile regiunilor nu diferă fundamental de alte funcții GDI, cu toate acestea, crearea de obiecte regiune și operațiunile cu acestea sunt asociate cu costuri semnificative de timp și memorie, mai ales atunci când forma regiunii devine mai complexă Dacă forma regiunii poate fi reprodusă cu ușurință de alte instrumente GDI (dreptunghiuri, elipse, dreptunghiuri rotunjite și trasee), această metodă ar trebui să fie preferată Funcțiile de redare a regiunii ar trebui folosite pentru a înlocui operațiunile mai costisitoare, cum ar fi funcțiile de un singur pixel sau de umplere Să presupunem că o aplicație desenează două cercuri suprapuse pe ecran și vrea să picteze peste zona comună cu un fel de pensulă În implementările moderne ale GDI, nu este atât de ușor să obțineți definițiile celor două arce care delimitează această zonă, dar folosind GDI, puteți calcula cu ușurință intersecția a două regiuni circulare G-radient umple umpleri cu gradient Până de curând, instrumentele GDI vă permiteau să pictați o zonă închisă cu o pensulă solidă monocoloră, o pensulă punctată cu două culori sau o pensulă cu model, numărul de culori în care era determinat de numărul de culori din raster Dar, odată cu proliferarea adaptoarelor video și a imprimantelor cu adâncime crescută a culorii, aplicațiile au început să folosească mai multe culori pentru a face imaginea să pară mai atractivă Una dintre varietățile de efecte de culoare sunt umplerile cu degrade - umplerea unei zone cu numeroase culori generate conform unei anumite reguli Suportul pentru umplerile cu gradient a fost implementat pentru prima dată în aplicații profesionale (cum ar fi Photoshop, CorelDraw și Microsoft Office) Începând cu Windows și Windows , umplerile cu gradient au devenit parte din GDI În Win GDI, suportul pentru umplerile cu gradient este oferit de o singură funcție definită de trei structuri de date noi typedef struct TRIVERTEX { LUNG x; Y LUNG: C L R Roșu: C L R Verde: C L R Albastru: C L R Alfa: } TRIVERTEX * PTRIVERTEX, * LPTRIVERTEX: typedef struct GRADIENT TRIANGLE { ULONG Vertexl: ULONG Vertex : ULONG Vertex : } GRADIENTJRIANGLE, *PGRADIENT TRIANGLE *LPGRADIENTJRIANGLE: typedef struct GRADIENT RECT { ULONG sus stânga: ULONG Dreapta Inferioară; } GRADIENT RECT *PGRADIENT RECT, *LPGRADIENT RECT; BOOL GradientFill(HDC hDC CONST PTRIVERTEX pVertex DWORD dwNumVertex CONST PVOID pMesh DWORD dwNumMesh, DWORD dwMode): Funcția GradientFill are o serie de caracteristici distinctive În primul rând, nu există prefixe lungi și îndepărtate moștenite de la Win în fața tipurilor de pointer În al doilea rând, un nou canal alfa a fost adăugat la formatul tradițional RGB cu canale În al treilea rând, canalele de culoare pe biți nu sunt suficiente, așa că sunt folosite canale pe biți Toate acestea indică clar îmbunătățirea treptată a API Funcția GradientFill umple unul sau mai multe dreptunghiuri (sau triunghiuri, în funcție de ultimul parametru dwMode) În acest moment, parametrul dwMode poate lua trei valori valide, enumerate în Tabel Capitolul Tabelul Moduri ale funcției GradientFill Valoarea parametrului dwMode Semnificație GRADIENT FILL RECT H Dreptunghiul este umplut cu culori care se schimbă de la stânga la dreapta Culoarea verticală rămâne constantă GRADIENT FILL RECT V Dreptunghiul este umplut cu culori care se schimbă de sus în jos Pe orizontală culoarea rămâne constantă GRAD LENT-FILLRECTTRI ANGLE Triunghi umplut cu culori interpolate din trei vârfuri Un singur dreptunghi sau triunghi se numește „celulă” (plasă) - acest termen argou provine de la programarea jocurilor pe calculator Numărul de celule este trecut în parametrul dwNumMesh; pointerul pMesh se referă la o serie de structuri (fie GRADIENT RECT sau GRADIENT TRIANGLE) Structura GRADIENT RECT conține indicii colțurilor din stânga sus și din dreapta jos ale dreptunghiului Structura GRADIENT TRIANGLE conține indicii celor trei vârfuri ale unui triunghi Indicii se referă la matricea TRIVERTEX la care se face referire de parametrul pVertex Parametrul dwNumVertex specifică numărul de elemente din tabloul TRIVERTEX Deci, pentru vârful fiecărui dreptunghi sau triunghi, există o structură TRIVERTEX care îi definește poziția și culoarea Poziția este specificată într-un sistem de coordonate logic folosind valori de de biți Culoarea lor este determinată de patru canale pe biți (roșu, verde, albastru și canal alfa) Pentru o umplere cu gradient orizontal a unui dreptunghi, dacă colțul din stânga sus are coordonate (x , y ), iar colțul din dreapta jos are coordonate (x , yy), culoarea punctului (x, y/) este calculată prin formula: С(х у) = ( C(xl yl) * (х-хО) + С(хО уО) * (хі-х)) / (хІ-хО) Aici C(x, y) înseamnă intensitatea unuia dintre canalele de culoare în punctul (x, y) O umplere cu gradient vertical pentru dreptunghiuri folosește o formulă similară, în funcție de coordonata y С(х у) = ( С(хі уі) * (у-уО) + С(хО уО) * (уі-у)) / (yl-yO) Cu umplerile cu gradient pentru triunghiuri, situația este ceva mai complicată Dacă trei vârfuri au coordonatele {x , y ), (x , y ) și (x , y/ ), atunci pot fi trase trei segmente din punctul interior (x, z/), împărțind triunghiul în trei triunghiuri mai mici Dacă ai este aria triunghiului opus punctului (xi, yi), culoarea în punctul (x, y) se calculează prin formula: C(x y) = ( C(xO yO) * aO + C(x ,y ) * ai + C(x y ) * a ) / (aO + ai + a ) Pentru dreptunghiuri, formula de interpolare depinde de distanță, deci este firesc ca formula de interpolare pentru triunghiuri să depindă de zonă Pentru dreptunghiuri, culoarea formează o linie dreaptă pe planul format din una dintre axe și fiecare canal de culoare Cu o umplere în gradient a unui triunghi, culoarea formează un plan în spațiul D format din axele x, y și fiecare canal de culoare G-radient umple Dreptunghiuri de umplere cu gradient Pentru a explora utilizarea funcției GradientFI cu un exemplu specific, să încercăm să creăm diferite umpleri cu gradient pentru aceeași regiune dreptunghiulară Cu câte opțiuni poți veni? Cele mai comune combinații sunt prezentate în fig Orez Zona dreptunghiulară de umplere cu gradient Cele patru umpleri de sus își schimbă culoarea într-o direcție - de la stânga la dreapta, de sus în jos sau în diagonală În rândul următor, dreptunghiul este împărțit în două părți, iar umplerea se efectuează din centru în direcții opuse În rândul de jos, umplerea se extinde de la un colț la întregul dreptunghi În ultimele două exemple (pe dreapta), umplerea merge de la calea exterioară la centru Codul folosit pentru a construi această figură este prezentat parțial în Lista Lista Zone dreptunghiulare de umplere cu gradient inline C L R R (COLORREF c) { return GetRValue(c)" ; } inline C L R G CCOLORREF c) { return GetGValue(c)" ; } inline C L R B CC L RREF c) { return GetBValue(c)" : } inline C L R R (COLORREF cO, COLORREF cl) { return ((GetRValue(cO)+GetRValue(cl))/ )" : } inline C L R G CC L RREF cO COLORREF cl) { return ((GetGValue(cO)+GetGValue(cl))/ )" : } inline C L R B (C L RREF cO COLORREF cl) { return ((GetBValue(cO)+GetBValue(cl))/ )" : } BOOL GradientRectangle CHDC hDC, int xO int yO, int xl intyl COLORREF co COLORREF cl unghi int) { TRIVERTEX vertE ] = { {xO yO R (c ) G (c ) B (c ) } {xl yl R (cl) G (cl) B (cl) } Continuare Capitolul Lista Continuare {xO yl R (c , сі), G (c ci) B (с , сі), } { хі yO R (c ci) G (c , сі) В (сО сі), } }: ULONG IndexE] = { , , , , , }: comutator (unghi % ) { cazul : return GradientFill(hDC, vert, , Index, , GRADIENT FILL RECT H); cazul : returnează GradientFill(hDC, vert , Index GRADIENT FILL TRIANGLE): cazul : return GradientFill(hDC vert Index, GRADIENT FILL RECT V); cazul : vert[ ] x = xl; vert[ ],x = xO: vert[l] x = xO: vert[ J x = xl; return GradientFill(hDC, vert, , Index, GRADIENT FILL TRIANGLE); } returnează FALSE; } BOOL CornerGrad entRectangle(HDC hDC int xO int yO int xl intyl COLORREF co COLORREF cl colț int) { TRIVERTEX vert[] = { {xO, yO R (CI), G (CI), B (CI), } {xl yO R (cl) G (CI), B (CI), } {xl yl, R (CI), G (CI), B (CI) } {xO,yl R (cl), G (cl) B (cl) } }: vertEcorner] Red =R (cO): vertEcorner] Verde = G (c ): vertEcorner] Albastru = B (c ); ULONG IndexE] = { colț, (colț+W , (colț+ )% colţ (colț+ )M (colț+ W}: returnează GradientFIlKhDC vert , Index, GRADIENT FILL TRIANGLE): } Funcția GradientRectangle atrage patru umpleri din primul rând; primul și al treilea poligoane folosesc o umplere dreptunghiulară simplă G-radient umple Al doilea și al patrulea exemplu sunt desenate cu o umplere triunghiulară Funcția CornerGradientRectangle desenează patru umpleri în al treilea rând, toate folosind o combinație de două triunghiuri Fragmentul de mai sus definește mai multe funcții inline pentru a converti valorile RGB de biți în valori de biți utilizate în structura TRIVERTEX și pentru a calcula culorile medii Rețineți că structurile GRADIENT RECT și GRADIENT TRIANGLE nu sunt implicate în exemplul de mai sus; în schimb, lucrăm direct cu matrice de indici lungi nesemnați Aplicarea umplerilor cu degrade pentru a crea butoane D Combinația mai multor umpleri cu gradient creează efecte interesante Datorită mecanismului de tăiere, umplerile cu gradient pot fi aplicate și pe zone nedreptunghiulare; de exemplu, vă permite să simulați aspectul tridimensional al butoanelor Pe fig Figura prezintă trei butoane tridimensionale create folosind funcția GradientRectangle Orez Aplicarea umplerilor cu degrade pentru a crea butoane D Primul buton dreptunghiular este desenat prin umplere în gradient de la întuneric la deschis și apoi de culoare deschisă la închisă pe o zonă mai mică Rezultatul este o impresie de suprafață curbată Următoarele două butoane sunt create într-un mod similar, dar folosesc decuparea pe dreptunghiuri și elipse rotunjite De fapt, toate cele trei butoane sunt tăiate pe regiune sub formă de dreptunghiuri rotunjite cu grade diferite de colțuri rotunjite Funcția de creare a butoanelor este prezentată mai jos void RoundRectButton(HDC hDC Int xO Int yO Int xl Int yl, Int w, Int d, COLORREF cl COLORREF co) pentru (Int = ; xl ) { int t = xO: xO = xl; xl = t; } if ( yO>yl ) { int t = yO; yO = yl; yl = t: } pentru (int y=yO; y &&&&&&& >&&&&&&& Învață Orez Amestecare atunci când pictați cu o pensulă uniformă pe dispozitivele care folosesc o paletă Rezultate Acest capitol acoperă instrumentele GDI pentru umplerea zonelor închise - pensule, umpluturi, regiuni și umpleri cu gradient fantezis Spre deosebire de pixuri, care au propriile dimensiuni geometrice, o perie determină doar modul în care un model de culoare este plasat într-o zonă închisă Am explorat în detaliu situațiile în care capabilitățile limitate ale pensulelor GDI nu îndeplinesc cerințele aplicațiilor moderne, am rezolvat problemele de incompatibilitate între sistemele de operare și am acoperit câteva soluții, soluții și recomandări generale O perie GDI este o specificație logică a unei perii reale care este utilizată de driverul de dispozitiv atunci când desenează și este de obicei dependentă de hardware Prima dată când este utilizată o nouă perie logică, motorul grafic apelează driverul de dispozitiv pentru a implementa peria logică, adică pentru a crea o structură fizică de date bazată pe peria logică Obiectul perie implementat este apoi transmis tuturor funcțiilor driverului care folosesc peria Pentru mai multe informații despre structura de date internă a unei pensule, consultați descrierea altor obiecte GDI din Capitolul (Secțiunea „WinDbg și extensia GDI Debugger”) GDI oferă destul de multe funcții pentru a desena forme geometrice simple (dreptunghiuri, dreptunghiuri rotunjite, elipse și poligoane) Contururile unor astfel de figuri sunt conturate cu un stilou, iar interiorul este pictat cu o pensulă Figuri mai complexe sunt construite folosind Capitolul traiectorii care combină diferite tipuri de curbe La nivel DDI, aproape toate contururile sunt convertite în trasee, iar majoritatea apelurilor pentru a umple zonele închise sunt gestionate de implementarea internă a funcției StrokeAndFilIPath Chiar și poligoanele și colecțiile de poligoane sunt căi care constau numai din linii drepte Singura excepție este dreptunghiurile în modul grafic compatibil; folosesc punctul de intrare DDI mai simplu GDI este una dintre interfețele de bază de programare grafică și, prin urmare, nu acceptă un set destul de complet de operații geometrice Pe măsură ce cifrele devin mai complexe, calculul exact al contururilor lor devine o sarcină dificilă, dacă nu imposibilă Cea mai simplă soluție este să folosești regiuni Folosind operațiunile din teoria seturilor, puteți crea regiuni noi ca combinații de regiuni existente și le puteți aplica pentru trasare sau tăiere Pe de altă parte, utilizarea regiunilor necesită o cantitate semnificativă de memorie și timp de procesor, iar odată cu o creștere mare a regiunii, calitatea imaginii se deteriorează Există câteva funcții speciale în GDI pentru obținerea reprezentării interne a regiunilor și aplicarea transformărilor acestora Acest lucru deschide multe posibilități interesante, cum ar fi aplicarea transformărilor de perspectivă datelor din regiune În noile implementări ale Win GDI, instrumentele API pentru pictarea figurilor plate au intrat în a treia dimensiune, culoarea - a apărut suportul pentru umplerile cu gradient Umplerile cu gradient sunt adesea folosite pentru a simula evidențierea pe diferite suprafețe Este probabil ca în viitor acestea să fie din ce în ce mai frecvente în aplicații Deci, până acum ne-am familiarizat cu funcțiile de desenare a pixelilor și liniilor / curbelor individuali, precum și cu umplerea zonelor închise Începând cu următorul capitol, vom explora diferitele hărți de bit suportate de GDI și utilizările lor în continuă expansiune Exemplu de program Acest capitol este însoțit de un singur exemplu de program Zone (Tabelul ) Acest program ilustrează toate subiectele abordate în acest capitol și construiește toate figurile date în text Tabelul Programul capitolului Descriere director de proiect Samples\Chapt \Area Meniul Test conține mai mult de o duzină de comenzi care ilustrează amestecarea culorilor, aplicarea pensulelor de contur și model, pensule de culoare de sistem, dreptunghiuri de desen, elipse, sectoare, segmente, dreptunghiuri rotunjite, poligoane, seturi de poligoane, regiuni și căi și degrade umpleri Capitolul Înțelegerea rasterelor După cum se arată în ultimele trei capitole, pixelii, liniile și zonele închise pot fi utilizați pentru a construi diagrame financiare, desene inginerești, modele geometrice și așa mai departe Obiectele geometrice incluse într-o imagine sunt descrise prin formule matematice precise Această zonă a programării graficii pe computer este denumită în mod obișnuit grafică vectorială Un alt domeniu la fel de important al graficii pe computer folosește imagini digitalizate obținute din lumea exterioară Această zonă se numește grafică bitmap O imagine bitmap este o matrice dreptunghiulară de elemente (pixeli), fiecare având o anumită culoare Imaginile raster sunt adesea rezultatul procesării informațiilor introduse de la un scaner, o cameră digitală sau o cameră video Rasterele sunt un subiect prea larg, așa că această carte este împărțită în trei capitole Acest capitol este despre formatele bitmap și afișarea lor pe un dispozitiv grafic Ne vom uita la cele trei formate principale de bitmap acceptate de GDI - DIB (Device-Independent Bitmap), DIB Sections și DDB (Device-Dependent Bitmap) Următoarele capitole vor analiza aplicații practice - ieșire raster transparentă, suprapunere alfa pe o imagine de fundal, estompare înăuntru și ieșire, rotații raster etc Rastere independente de dispozitiv Când elementele grafice digitizate sunt introduse de la dispozitive, datele de imagine trebuie convertite într-un format adecvat pentru stocarea pe un hard disk al computerului sau pe alte medii și pentru transmiterea la un dispozitiv la distanță Există multe probleme cu formatele de imagini grafice în zilele noastre Diferite sisteme de operare, firme de proiectare hardware și chiar și cu Capitolul Înțelegerea rasterelor Aplicațiile funcționează cu grafică stocată în diferite formate Cele mai comune formate raster includ următoarele: Despre JPEG (dezvoltat de Joint Photographic Experts Group) - format de culoare pe de biți cu compresie și pierdere de date; Despre TIFF (dezvoltat de Aldus) este un format grafic foarte flexibil, cu suport pentru diferite subformate, ordinea octetilor MAC și PC și compresie LZW; Despre GIF (dezvoltator - CompuServe) - format grafic pentru imagini mici care nu conțin mai mult de de culori, cu suport pentru stepping și transparență; Despre PNG (www cdrom com/pub/png/), Portable Network Graphics este un format grafic cu suport pentru multe caracteristici exotice; astăzi se deosebește de alte formate prin folosirea algoritmilor neproprietari și distribuția liberă a textelor sursă Formatul grafic tradițional al sistemului de operare Microsoft Windows este formatul BMP În comparație cu alte formate grafice, acesta este un format foarte simplu care a fost conceput în primul rând pentru a simplifica programarea grafică în aplicații Suportul pentru adâncimea culorii BMP este destul de versatil, de la imagini indexate pe , , și biți până la culori pe , și de biți în modelul RGB Imaginile BMP tind să ocupe mult spațiu, deoarece formatul acceptă doar cea mai simplă formă de compresie RLE în formatele indexate pe și biți De exemplu, o imagine BMP de de biți, x pixeli este de , MB, în timp ce JPEG este de obicei comprimat la aproximativ KB Nu este recomandat să stocați imagini atât de mari pe un disc sau să le partajați pe Internet Format de fișier WMP Rasterele în format BMP sunt denumite în mod obișnuit Bitmap independent de dispozitiv (DIB) Definiția „independent de dispozitiv” înseamnă că formatul conține informații complete despre imagine și vă permite să o redați pe diferite dispozitive Inițial, termenul nu a însemnat că un bitmap a fost codificat într-un spațiu de culoare independent de dispozitiv, deși noile versiuni ale sistemelor de operare Microsoft includ date de profil de culoare în format BMP pentru a compensa dependența de dispozitivele color Bitmapurile independente de dispozitiv sunt opuse unui alt format de imagine utilizat în funcționarea interioară a sistemului grafic Windows - hărți de biți dependente de dispozitiv (Device-Dependent Bitmaps, DDB) În această secțiune, vom privi mai întâi DIB ca un format grafic fundamental pentru Windows și apoi vom trece la DDB și un alt format bitmap, secțiuni DIB Un raster independent de dispozitiv, sau DIB, stocat într-un fișier pe disc constă din trei componente principale: un antet de fișier raster, un bloc de descriere raster și o matrice de pixeli Blocul de descriere raster poate fi împărțit suplimentar într-un antet, o serie de măști și un tabel de culori (în funcție de adâncimea de culoare a rasterului) Pe fig Figura prezintă structura unei imagini DIB într-un fișier disc Rastere independente de dispozitiv Antet fișier bitmap (BITMAPFILEHEADER) Informații bitmap Antet bloc cu informații bitmap (BITMAPCOLORHEADER, BITMAPINFOHEADER, BITMAPV HEADER sau BITMAPV HEADER) Mască de biți (DWORD ) Tabel de culori (RGBTRIPLE[ ], RGBQUAD [ ]) Matrice de pixeli (PixeI[][]) Orez Format de fișier WMP Antetul fișierului raster Antetul bitmap conține informații simple pe care aplicațiile le folosesc pentru a identifica fișierele BMP Este alcătuit din trei componente principale: o semnătură de fișier BMP, un câmp pentru lungimea fișierului și un offset al matricei de pixeli Antetul este definit în structura BITMAPFILEHEADER typedef struct tagBITMAPFILEHEADER { WORD bfType; DWORD bfSize; DWORD bfReservedl; DWORD bfReserved ; DWORD bfOffBits; }BITMAFILEHEADER; // Semnătura fișierului BMP // Dimensiunea totală a fișierului // O // O // Offset al matricei de pixeli de la începutul fișierului Semnătura bfType din fișierele BMP constă din două caractere ASCII, „B” și „M”, astfel încât fișierul începe întotdeauna cu valoarea x D sau „M” * + „B” Câmpul bfSize stochează dimensiunea totală a fișierului grafic (acest lucru este util când încărcați fișiere de pe un computer la distanță) Ultimul câmp al structurii stochează offset-ul matricei de pixeli de la începutul fișierului grafic Rețineți că structura BITMAPFILEHEADER a fost concepută inițial pentru versiunile de Windows pe biți, așa că se aliniază la granițele cuvintelor, nu la cuvinte duble Dimensiunea totală a structurii este de octeți, drept urmare, antetul blocului de descriere raster nu este nici el aliniat pe o limită de cuvânt dublu Această circumstanță poate cauza probleme atunci când încercați să salvați o secțiune DIB într-un fișier bitmap mapat în memorie Capitolul Înțelegerea rasterelor Titlul descrierii raster Antetul fișierului bitmap spune doar aplicațiilor că fișierul conține date în format BMP, iar descrierea detaliată este stocată în blocul de informații care îl urmează, care începe și cu antetul Dacă antetul unui fișier bitmap a supraviețuit mai multor generații de sisteme de operare Windows fără cea mai mică modificare, antetul blocului de descriere cu informații despre bitmap s-a schimbat de multe ori în trecut și continuă să se schimbe Conține informații despre formatul bitmap-ului, dimensiuni, schema de compresie, dimensiunea tabelului de culori, profiluri de culoare și multe altele În prezent, există patru versiuni diferite ale acestui antet Cea mai simplă dintre acestea este structura BITMAPCOREHEADER, concepută inițial pentru sistemul de operare OS/ typedef struct tagBITMAPOREHEADER { DWORD bcSize: WORD bcWidth; // sizeof(BITMAPCOREHEADER) // lățimea hărții de biți în pixeli WORD bcHeight: // înălțime bitmap în pixeli + orientare WORD bcPlanes; // numărul de avioane, trebuie să fie egal cu WORD bcBitCount: } BITMAPCOREHEADER: // numărul de biți pe pixel Cel mai adesea, fișierele BMP folosesc un antet în formatul structurii BITMAPINFOHEADER, care este extins semnificativ în comparație cu versiunea OS / typedef struct tagBITMAPOREHEADER { DWORD bcSize; // sizeof(BITMAPOREHEADER) WORD bcWldth; // lățimea bitmap-ului în pixeli CUVÂNT bcÎnălțime; // înălțimea bitmap-ului în pixeli + orientare WORD bcPlanes: // numărul de avioane, ar trebui să fie WORD bcBitCount; // numărul de biți pe pixel DWORD biCompression: // algoritm de compresie DWORD biSizelmage: // dimensiunea matricei de pixeli LONG blXPelsPerMeter; // rezoluție orizontală LONG bYPelsPerMeter; // rezoluție verticală DWORD biClrUsed; // dimensiunea totală a tabelului de culori DWORD biCirImportant; // numărul de culori necesare pentru ieșire } BITMAPCOREHEADER; Structura BITMAPINFOHEADER este denumită în mod obișnuit „versiunea ” a descrierii bitmap Toate aspectele API-ului Win care datează din Windows sunt de obicei denumite „versiunea ”; noile caracteristici adăugate în Windows și Windows NT sunt denumite „versiunea ”, în timp ce noile funcții din Windows și Windows sunt denumite „versiunea ” Windows și Windows NT au introdus noua structură BITMAPV HEADER, iar Windows și Windows au adăugat structura BITMAPV HEADER Începutul acestor noi structuri este exact același cu BITMAPINFOHEADER (cu excepția faptului că câmpul de dimensiune conține sizeof(BITMAPV HEADER) sau, respectiv, sizeof(BITMAPV HEADER) Structura versiunii are noi câmpuri pentru măștile de culoare RGBA, spațiile de culoare, punctele finale și corecția gama, care a fost destinat să accepte ICM Structura versiunii adaugă noi tipuri de spațiu de culoare, linii directoare de randare și date Rastere independente de dispozitiv profil de culoare, axat pe suportul ICM Consultați MSDN pentru descrieri detaliate ale acestor structuri În mod ironic, faptul că componenta grafică Win generează fișiere BMP cu antet V este considerat mai degrabă un dezavantaj decât un avantaj, deoarece nici Visual Basic nu citește fișiere BMP noi Cu toate acestea, o aplicație bine scrisă ar trebui să poată primi cel puțin anteturi BMP în patru formate diferite, chiar dacă ignoră noile câmpuri V și V și interpretează antetul ca o structură BITMAPINFOHEADER În structurile antet, primul câmp determină dimensiunea structurii și este singura indicație prin care este posibil să se determine ce versiune a antetului este utilizată Dacă câmpul este egal cu sizeof(BITMAPCOREHEADER), aplicația trebuie să funcționeze cu DIB-uri în format OS/ Câmpul de dimensiune definește, de asemenea, offset-ul la care se află tabelul de culori DIB Următoarele două câmpuri stochează lățimea și înălțimea DIB-ului în pixeli Rețineți că OS/ DIB-urile stochează aceste valori ca cuvinte de biți (WORD), în timp ce versiunile mai noi folosesc un tip LONG de de biți Înălțimea DIB este de obicei o valoare pozitivă, dar poate fi și negativă Semnul determină ordinea liniilor de scanare în matricea de pixeli O înălțime DIB pozitivă corespunde ordinii inverse a rândurilor (de jos în sus), unde primul pixel al matricei este primul pixel al ultimei linii de scanare a imaginii; astfel de rastere DIB sunt numite de jos în sus Înălțimea negativă a DIB corespunde ordinii de scanare directă mai obișnuită (de sus în jos) Majoritatea fișierelor BMP folosesc ordinea inversă a liniei de scanare Câmpurile bcPlanes și bcBitCount definesc formatul liniilor de scanare ale matricei de pixeli În imaginile în două culori, dintre care imaginile alb-negru sunt un caz special, un bit este suficient pentru a reprezenta un pixel În imaginile cu de culori, un pixel este reprezentat de biți Dispozitivele grafice diferite pot utiliza structuri de linie de scanare diferite (cu unul sau mai multe planuri de culoare), dar formatul DIB acceptă doar imagini cu un singur plan, astfel încât câmpul bcPlanes trebuie să fie egal cu Câmpul bcBitCount definește complet dimensiunea fiecărui pixel și numărul de culori reprezentat de un pixel Valorile valide ale acestui câmp sunt listate în tabel Tabelul Valori valide ale câmpului bcBitCount în format DIB Valoare Număr maxim Dimensiunea vârfului Descrierea culorilor satului, octeți Depinde de imaginea încorporată Acceptat numai pe Windows / ; folosit pentru a încorpora imagini JPEG sau PNG ( ') / Imagine monocromă Continuare Capitolul Înțelegerea rasterelor Tabelul Continuare Valoare Număr maxim de culori Dimensiunea pixelilor, octeți Descriere ( ) / Imagine cu culori utilizată în WinCE ( ) / imagine color ( ) imagine color ( '=) sau ( ) Culoare mare ( ) True Color ( ) True Color Dacă numărul de biți pe pixel este mai mic sau egal cu , un tabel de culori urmează antetul din fișierul BMP Structura BITMAPCOREHEADER utilizată pe OS/ se termină cu un câmp bcBitCount, iar alte structuri au câmpuri suplimentare Formatul DIB de bază trebuie interpretat de aplicație, astfel încât câmpurilor lipsă li se atribuie valori implicite Câmpul biCompression stochează informații despre algoritmul de compresie aplicat matricei de pixeli Valorile permise sunt listate în tabel Tabelul Algoritmi de compresie DIB Descrierea valorii BI RGB Imagine necomprimată BI RLE O imagine codificată de biți/pixeli comprimată folosind algoritmul RLE Numai pentru rasterele DIB inversate BI RLE Imagine codificată de biți/pixel comprimată folosind algoritmul RLE Numai pentru rasterele DIB inversate BI BITFIELDS Imagini necomprimate codificate pe și biți/pixel În imagine sunt incluse măști de trei biți pentru a determina modul în care sunt stocate componentele RGB BIJPEG O matrice de pixeli care conțin o imagine JPEG încorporată Acceptat numai pe Windows / BI PNG O matrice de pixeli care conține o imagine PNG încorporată Acceptat numai pe Windows / Cel mai frecvent, câmpul biCompression este BI RGB (fără compresie) Visual Studio și editorii grafici de la Microsoft generează fișiere BMP numai în format necomprimat În absența compresiei, fiecare linie de scanare DIB este o matrice plină de pixeli Un pixel codificat pe bit ocupă / octet, un pixel codificat pe biți ocupă / octet și pixeli Rastere independente de dispozitiv cu o codificare pe biți ocupă / octet În aceste trei cazuri, un octet poate conține datele mai multor pixeli, de la bitul cel mai semnificativ până la cel mai puțin semnificativ Pentru imagini cu un număr mare de biți / pixel, fiecare pixel ocupă biBitCount / octeți Liniile de scanare din rasterele independente de dispozitiv sunt întotdeauna aliniate la cea mai apropiată limită a cuvântului dublu (dacă este necesar, linia este completată cu zerouri) În DIB-urile cu codare de și biți/pixel, compresia opțională RLE (Run-Length En-coding) poate fi utilizată pentru a reduce dimensiunile rasterului Pentru imaginile pe biți, acest algoritm caută o secvență de octeți învecinați cu aceeași valoare și îi înlocuiește cu doi octeți: numărul de repetiții și codul octetului repetat Sunt furnizate secvențe de servicii speciale pentru octeții care nu se repetă, sfârșitul unei linii și sfârșitul unei imagini Algoritmul RLE oferă cel mai bun rezultat dacă fiecare linie de scanare constă din aceiași pixeli În cel mai rău caz, rezultatul ocupă mai mult spațiu decât imaginea originală necomprimată Mai jos este o descriere a formatului de imagine comprimată folosind metoda BI RLE : :: = { } ::= | ::= | | | ::= O O ::= dx dy ::= counter { byte } repetition count repeat byte Imaginea comprimată în format RLE este codificată ca o serie de serii de pixeli care există în cinci forme Dacă primul octet al seriei de pixeli este altceva decât un marcator, este un număr de repetiții (de la la ) și indică de câte ori se repetă următorul octet Dacă primul octet este zero, următorul octet trebuie să fie fie (sfârșitul liniei), (sfârșitul imaginii), (delta) sau - (pixeli necomprimați) Seria delta schimbă poziția curentă în imaginea decodificată cu decalaje date de-a lungul axelor x și z/, ceea ce vă permite să depășiți rapid mai multe linii de scanare Indicațiile de sfârșit de linie și de sfârșit de imagine permit, de asemenea, oprirea prematură a liniilor de scanare sau a imaginilor, dar valorile pixelilor lipsă sunt considerate nedefinite Astfel, în practică, seriile delta practic nu apar; Semnele de sfârșit de linie și de sfârșit de imagine sunt de obicei plasate după ultimul pixel al unei linii sau întreaga imagine Cu alte cuvinte, fiecare linie de scanare este de obicei codificată separat de restul fără săriți pixeli, evitând astfel valorile pixelilor nedefinite Serii imediate descriu secvențe de pixeli care nu se repetă într-o imagine Seria începe de la și contorul variază de la la , deoarece valorile - sunt rezervate pentru terminatorii de linie, terminatorii de imagine și seriile delta Contorul este urmat de numărul exact de octeți Fiecare serie imediată trebuie să fie un număr par de octeți, deci contorul trebuie să fie par Acest lucru asigură că fiecare serie de pixeli din imaginea codificată este întotdeauna Capitolul Înțelegerea rasterelor de-a lungul graniței cuvântului, ceea ce simplifică foarte mult procesele de codificare/restaurare a informațiilor și crește eficiența acestora Dacă pixelii nu sunt săriți într-o imagine codificată RLE, sintaxa acesteia este prezentată în următoarea formă simplificată: :: = { } E ] ::= { } E ] ::= | Imaginile codificate BI RLE pe patru biți au aceeași structură de bază ca și imaginile BIRLE Cu toate acestea, în acest caz, fiecare pixel este reprezentat de doar biți Contorul de date imediat conține numărul de pixeli, deci datele care urmează trebuie să fie (număr+ )/ octeți Numărul de repetiții conține și numărul de pixeli; octetul care îl urmează conține doi pixeli, care sunt utilizați alternativ pentru a umple numărul specificat de pixeli Pentru rasterele DIB pe și de biți, câmpul biCompression trebuie să fie egal cu BI BITFIELDS Această valoare nu se potrivește cu metoda reală de compresie; vă permite doar să setați dimensiunea și ordinea componentelor roșii, verzi și albastre într-un pixel Dacă câmpul biCompression conține BI FIELDS, trei cuvinte duble sunt adăugate după antetul blocului de descriere raster și înaintea tabelului de culori - măști pentru extragerea componentelor roșii, verzi și albastre din pixeli împachetati pe sau de biți La prima vedere, măștile par a fi extrem de flexibile și permit crearea a tot felul de formate DIB exotice, dar în realitate trebuie să fie supuse unei serii de restricții Pe sistemele din familia NT, măștile trebuie să fie formate din pixeli adiacenți și nu trebuie să se suprapună Cu toate acestea, puteți crea în continuare un DIB cu o ordine de canale RGB non-standard Pe sistemele care nu fac parte din familia NT, sunt acceptate doar trei tipuri de măști Pentru imaginile pe biți, sunt acceptate numai formatele RGB - - și - - În formatul - - , masca albastră este xlF, masca verde este x , iar masca roșie este x C , iar fiecare canal ocupă biți În formatul - - , masca albastră este xlF, masca verde este x E , iar masca roșie este xF ; dintre aceste trei canale, doar canalul verde ocupă biți Pentru imaginile pe de biți, este acceptat doar formatul - - , unde masca albastră este xFF, masca verde este xFFOO și masca roșie este xFFOOOO De fapt, măștile de biți au fost dezvoltate pentru a rezolva problemele de compatibilitate asociate cu diferențele în implementările modurilor High Color Ghidul de proiectare a sistemului PC afirmă că adaptorul video trebuie să accepte un buffer de cadre cu rânduri în format - - sau - - sau ambele Dacă este acceptat doar - - , adaptorul video trebuie să îl raporteze ca pe biți, nu pe biți, altfel unele aplicații s-ar putea rupe Un framebuffer pe de biți necesită suport pentru formatul - - - , unde cei biți superiori conțin datele canalului alfa Destul de ciudat, canalul alfa nu este documentat pentru blocul de descriere raster Rastere independente de dispozitiv Privind tipurile BI JPEG și BI PNG, se pare că GDI încearcă în sfârșit să rezolve problema bitmap-urilor DIB High Color și True Color mari, necomprimate, dar soluția propusă este doar o jumătate de măsură Aceste două moduri de compresie sunt acceptate numai pe Windows și Windows și cu anumite limitări GDI și motorul grafic de bază nu oferă niciun suport pentru decodarea imaginilor JPEG și PNG Acest suport nu este oferit nici de driverele video; numai driverele de imprimantă în voie îl pot implementa Pentru a verifica dacă JPEG sau PNG este acceptat, o aplicație trebuie să interogheze contextul dispozitivului imprimantei utilizând funcția ExtEscape; numai după ce a primit un răspuns pozitiv aplicația poate trimite un bitmap JPEG sau PNG comprimat înfășurat în DIB către driverul de dispozitiv În acest caz, GDI transmite pur și simplu datele driverului de imprimantă Acest lucru rezolvă doar parțial problema cu costurile uriașe de memorie ale stocării rasterelor DIB mari în formate High Color sau True Color Tipul BI JPEG este tratat în Capitolul Să revenim la structurile antetului blocului de descriere raster Atributul de compresie este urmat de câmpul biSizelmage, care stochează dimensiunea matricei de pixeli a imaginii Când se utilizează valoarea BI RGB, câmpul biSizelmage poate fi setat la ; GDI calculează dimensiunea unei imagini din lățimea, înălțimea și biți pe pixel Dar când comprimați RLE, JPEG sau PNG, acest câmp trebuie să conțină dimensiunea reală a datelor imaginii Ultimele două câmpuri ale structurii BITMAPINFOHEADER conțin informații despre tabelul de culori Câmpul biClrUsed stochează numărul de elemente din tabelul de culori Pentru un DIB cu nu mai mult de de culori, o valoare zero în câmpul biClrUsed înseamnă numărul maxim posibil, adică A(bps) Fișierul DIB de disc trebuie să conțină tabelul complet de culori cu numărul maxim de elemente Un tabel de culori incomplet poate fi utilizat numai în hărțile de biți DIB din memorie Câmpul biCl rlmportant definește numărul de elemente efectiv necesare pentru afișarea rasterului Ca și înainte, o valoare zero înseamnă că toate culorile din tabel sunt semnificative Fiecare element al tabelului de culori este de obicei de octeți (cu excepția vechiului format OS/ ), care oferă un total de de octeți pentru un DIB de biți/pixel Desigur, într-o lume Winl cu un heap de K GDI, această suprasarcină de memorie trebuia optimizată În programarea Win de de octeți, nimeni nu acordă atenție decât dacă programul tău funcționează cu sute sau mii de imagini Câmpul biClrlmportant spune aplicației doar câte culori sunt utilizate efectiv în imagine Pe baza acestor informații, programul poate genera o paletă exact de dimensiunea potrivită pentru a afișa imaginea în framebuffer Pentru hărțile de biți DIB color în formate High Color sau True Color, nu este necesar un tabel de culori, deoarece fiecare pixel conține informații complete despre toate componentele de culoare RGB Pe de altă parte, aceste rastere pot conține câmpuri non-nule biClrUsed și biClrlmportant și un tabel de culori Tabelul de culori din imaginile High Color și True Color poate fi folosit pentru a construi o paletă pentru ieșirea DIB pe dispozitive cu palete Paletele sunt tratate în Capitolul Capitolul Înțelegerea rasterelor Măști de biți Într-un raster DIB de sau de biți, dacă câmpul biCompression este BI BITFIELDS, antetul blocului de descriere raster este urmat de măști de biți stocate ca o matrice DWORD Trei măști sunt întotdeauna folosite în ordinea tradițională roșu-verde-albastru GDI nu furnizează nicio structură de date sau funcții API pentru gestionarea măștilor de biți tabel de culori În rasterele DIB care conțin nu mai mult de de culori, fiecare pixel de matrice conține un index al tabelului de culori, conform căruia indicii sunt convertiți în valori RGB Rasterele DIB în formatele True Color și High Color pot conține și tabele de culori pentru construirea de palete logice în sistemele cu palete Numărul de elemente din tabelul de culori este specificat în câmpul biClrllsed din antetul blocului de descriere raster Dacă acest câmp este (și, de asemenea, în format OS/ DIB), se presupune numărul maxim de elemente Elementele tabelului de culori sunt împărțite în trei tipuri Într-un OS/ DIB, fiecare element este reprezentat printr-o structură RGBTRIPLE, iar în alte formate DIB, printr-o structură RGBQUAD Pentru DIB-urile în memorie, fiecare element poate fi un cuvânt de biți care reprezintă indexul următorului nivel Atât în RGBTRIPLE cât și în RGBQUAD, culoarea este specificată de valori RGB pe biți După cum puteți vedea din definițiile de mai jos, aceste structuri diferă doar prin prezența unui câmp rezervat typedef struct tagRGBTRIPLE { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; } RGBTRIPLE; typedef struct tagRGBQUAD { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; BYTE rgbtReserved; }RGBQUAD; GDI definește două structuri suplimentare, BITMAPCOREINFO și BITMAPINFO, în care antetul blocului de descriere bitmap este combinat cu un tabel de culori typedef struct tagCOREINFO { BITMAPCOREHEADER bmcIHeader; RGBTRIPLE bmciColorsElJ; } BITMAPCOREINFO; typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; RGBQUADbmiColorsEl]; } BITMAPINFO; Trebuie avut grijă atunci când utilizați aceste structuri, deoarece ambele structuri rezervă spațiu doar pentru un singur element al tabelului de culori Rastere independente de dispozitiv Prin urmare, pentru a stoca antetul descrierii bitmap și tabelul de culori, aplicația trebuie să aloce memorie suplimentară în afara acestor structuri Câmpul bmiHeader al unei structuri BITMAPINFO poate fi de tip BITMAPINFOHEADER, BITMAPV HEADER sau BITMAPV HEADER, astfel încât offset-ul câmpului bmiColors nu este o valoare fixă Chiar dacă vă limitați la structura BITMAPINFOHEADER, nu există spațiu rezervat pentru măști de biți în rasterele DIB de și de biți O aplicație nu trebuie să se bazeze pe conținutul unei structuri BITMAPINFO atunci când caută un tabel de culori raster În schimb, compensarea tabelului de culori ar trebui calculată în timpul execuției pe baza datelor din antetul blocului de descriere raster Matrice de pixeli Pixelii unei imagini sunt stocați într-o matrice de pixeli În mod obișnuit, o imagine este o secvență de linii de scanare căptușite până la cea mai apropiată limită de de biți Liniile de scanare sunt stocate implicit în ordine inversă, cu excepția cazului în care câmpul biHeight din antetul descrierii este o valoare negativă Ordinea inversă a liniei de scanare înseamnă că primul pixel al matricei corespunde de fapt cu primul pixel al ultimei linii de scanare atunci când este afișat în modul MM TEXT În interiorul liniilor de scanare, pixelii sunt împachetati pentru a economisi spațiu Șirurile sunt umplute cu biți până la o limită de cuvinte duble Numărul de octeți pe linie de scanare, una dintre caracteristicile importante ale DIB, este calculat prin următoarea funcție: int inline ScanlineSize(int width int bitcount) return (lățime * număr de biți + )/ ; } Pentru un DIB cu modul de compresie BI RGB, accesarea pixelilor individuali dintr-o matrice este o operațiune simplă care este implementată destul de eficient Accesul direct la pixeli joacă un rol important în implementarea algoritmilor grafici și în îmbunătățirea instrumentelor de ieșire raster acceptate în GDI De asemenea, această tehnică este extrem de importantă în programarea DirectDraw, unde suprafața grafică este de fapt un DIB Detaliile vor fi discutate mai jos Bitmap complet independent de dispozitiv Formatul de fișier BMP este conceput pentru a stoca rasterele DIB ca fișiere pe disc După cum sa menționat mai sus, un fișier BMP constă dintr-un antet de fișier, un bloc de descriere raster și o matrice de pixeli Antetul fișierului conține informații utilizate la încărcarea DIB-ului în memorie Dar odată ce fișierul este în memorie, nu este nevoie de un antet Dacă este necesar, antetul fișierului poate fi recuperat din antetul blocului de descriere raster Un DIB fără antet de fișier se numește raster DIB împachetat Termenul „împachetat” în acest caz nu are nimic de-a face cu împachetarea pixelilor într-o linie de scanare Indică doar că restul componentelor DIB se succed în blocuri de memorie învecinate Capitolul Înțelegerea rasterelor Un raster DIB împachetat începe cu un antet de bloc de descriere raster, urmat de o serie de măști, un tabel de culori și o matrice de pixeli API-ul Win utilizează în mod obișnuit un pointer către o structură BITMAPINFO ca indicator către o hartă de biți DIB împachetată Deși această structură nu conține referințe la matrice de măști și pixeli, cel puțin puteți afla din ea despre prezența unui tabel de culori Un număr destul de mare de funcții API primesc și returnează rasterele DIB împachetate Dacă DIB-ul este inclus ca resursă în executabil, puteți utiliza funcțiile FindResource, LoadResource și LockResource pentru a obține un pointer către bitmap-ul DIB împachetat Funcția CreateDIBPatternBrushPt folosește un bitmap DIB împachetat pentru a crea o pensulă de model În plus, rasterele DIB împachetate sunt utilizate și în clipboard-ul Windows Într-un bitmap DIB stocat în memorie, un tabel de culori poate conține indecși de paletă logică De exemplu, dacă parametrul iUsage al funcției CreateDIBPatternBrushPt este DIB PAL COLORS, tabelul de culori este o matrice de indici Cu toate acestea, un astfel de bitmap DIB NU TREBUIE să fie transmis altor aplicații sau scris pe disc decât dacă cealaltă parte este conștientă de acest fapt Nu există niciun semnalizare în formatul de fișier DIB care să indice că tabelul de culori conține indecși ai unei palete necunoscute Raster împărțit independent de dispozitiv Conținutul unui raster DIB împachetat poate fi împărțit în două părți: o serie de pixeli și informații despre formatul raster (antetul blocului de descriere raster, măști și un tabel de culori) Păstrarea acestor două părți împreună este incomod De exemplu, un editor grafic care să suporte operațiuni de anulare pe mai multe niveluri poate stoca mai multe rastere DIB intermediare; toate conțin exact aceleași informații de format și diferă doar prin matricea de pixeli Există și alte situații - de exemplu, o aplicație poate primi o imagine într-un format diferit (PCX, TIFF sau GIF), poate crea o structură BITMAPINFO în memorie, poate construi o matrice de pixeli din datele recuperate și apoi încearcă să-i transfere două blocuri ca DIB Multe funcții grafice GDI sunt suficient de flexibile pentru a nu necesita transmiterea unui bitmap DIB împachetat În schimb, doi parametri sunt trecuți funcției - un pointer către o structură BITMAPINFO și un pointer către o matrice de pixeli Această soluție oferă flexibilitatea necesară la construirea DIB-urilor în memorie Uneori, un bitmap divizat independent de dispozitiv (un bitmap DIB dezambalat) conține un tabel de culori incomplet pentru a economisi spațiu De exemplu, când utilizați un DIB cu de nuanțe de gri, puteți aloca memorie pentru de intrări în tabelul de culori în loc de Clasa pentru lucrul cu DIB Deși BMP este considerat unul dintre cele mai simple formate grafice, descrierea dată în secțiunea anterioară nu pare simplă Complexitate Clasa pentru lucrul cu DIB Fișierele BMP se datorează dezvoltării constante a formatului pentru a suporta noi funcții și căutării constante a unui compromis între viteză și costurile de memorie Programarea grafică a bitmaps-urilor independente de dispozitiv nu este o sarcină ușoară, iar suportul pentru operațiuni cu bitmaps în API-ul GDI este destul de limitat De exemplu, nu există funcții în GDI care să returneze numărul de culori din tabelul de culori al unui bitmap DIB împachetat sau un pointer către o matrice de pixeli într-un bitmap DIB împachetat Programatorii trebuie să-și scrie propriul cod pentru a analiza diferite versiuni de structuri și pentru a obține informațiile de care au nevoie La nivel GDI, nu există suport pentru sarcini mai complexe - de exemplu, calcularea adresei unui pixel cu coordonate (x, z /) într-o matrice de pixeli sau convertirea unui raster în tonuri de gri Operațiunile DIB sunt bine încapsulate într-o clasă C++, dar nici biblioteca Microsoft Foundation Classes nu conține o clasă specializată pentru lucrul cu DIB-uri În această secțiune, vom începe să construim o clasă non-trivială pentru a face exact asta Principalele obiective de proiectare sunt enumerate mai jos A Încărcați și afișați DIB-urile în toate formatele DIB valide Imaginile de intrare pot proveni din surse diferite, astfel încât clasa trebuie să se poată încărca și afișa în toate formatele О Eficiența lucrului cu diverse date DIB Majoritatea informațiilor DIB sunt stocate în antetul blocului de descriere raster, care există în patru versiuni diferite cu valori implicite diferite O clasă DIB bine concepută ar trebui să returneze informațiile corecte cât mai repede posibil, fără verificări multiple Un acces direct la pixeli dintr-o matrice de pixeli necomprimată este cheia pentru implementarea multor algoritmi grafici Pe scurt, dorim să creăm o clasă DIB care să încarce și să afișeze DIB-uri în toate formatele posibile și, de asemenea, să funcționeze eficient cu imaginile True Color necomprimate Declarația clasei KDIB este prezentată în Listarea Lista Declarație de clasă KDIB typedef enumerare { DIB BPP, DIB BPP, DIB BPP, DIB BPPRLE, DIB BPP, DIB BPPRLE, DIBJ RGB , DIB- RGB DIB RGB , DIB RGB // Imagine cu culori // Imagine în culori cu paletă // Imagine cu culori // Imagine cu culori, // Compresie RLE // Imagine cu paletă de de culori // Imagine cu culori, // Compresie RLE // Imagine color RGB pe biți, - - , // bit nu este folosit // Imagine color RGB pe biți, - - // Imagine color RGB pe de biți, - - // Imagine color RGB pe de biți, - - , // biți nu sunt utilizați Continuare & Capitolul Înțelegerea rasterelor Lista Continuare DIB RGBA // Imagine color RGBA pe de biți - - - DIB RGBbitfields // Imagine color RGB pe biți // măști personalizate, numai NT DIB RGBbitfields // Imagine color RGB pe de biți // măști personalizate, numai NT DIB JPEG DIB PNG // Imagine JPEG încorporată // Imagine PNG încorporată } DIBFormat: typedef enumerare { DIB BMI NEEDFREE = DIB BMI READONLY = DIB BITS NEEDFREE = DIB BITS READONLY = }; clasa KDIB { public: DIBFormat m nImageFormat: // format de matrice de pixeli int m Flags: // DIB BMI NEEDFREE' BITMAPINFO * m pBMI://BITMAPINFOHEADER + mască + BYTE * m pBits: // // matrice de pixeli a tabelului de culori RGBTRIPLE * m pRGBTRIPLE: // DIB S/ tabel de culori în t rBMI RGBQUAD * m pRGBQUAD: // Tabel de culori DIB v , în t rBMI int m nCl rllsed: // numărul de culori din tabel int m nClrImpt: // numărul de culori utilizate DWORD *m pBitFields; // măști pentru și de biți/pixel int mjiWidth; // // în t rBMI lățimea imaginii în pixeli int m nHeight; // înălțimea imaginii în pixeli int m nPlanes: // H (pozitiv) număr de avioane int mjiBitCount: H biți pe plan int m nColorDepth: adâncimea culorii H int m nImageSize: // dimensiunea matricei de pixeli int m nBPS: // // Valori precalculate: dimensiunea liniei de scanare în octeți BYTE * m pOrigin; HH (pe plan) indicator către începutul logic al rasterului int m nDelta: // offset al următoarei linii de scanare KDIBO: virtual -KDIBO: // // // constructor implicit, creează un destructor virtual de imagine goală Clasa pentru lucrul cu DIB BOOL Lățimea creată, înălțimea int int bitcount): bool AttachDIBCBITMAPINFO * pDIB, BYTE * pBits, int flags); bool LoadF e(const TCHAR * pFIleName): bool LoadBitmap(HMODULE hModlue, LPCTSTR pBItmapName); void ReleaseDIB(void): // eliberează memoria int GetWidth(vold) const { return m nW dth: } int GetHeight(void) const { return m nHeight; } int GetDepth(vold) const { return m nColorDepth; } BITMAPINFO * GetBMI(void) const { return m pBMI; } BYTE * GetBits(void) const { return m pB ts; } int GetBPS(vold) const { return m nBPS; } bool IsCompressed(vold) const return (m nImageFormat == DIB BPPRLE) || (m nImageFormat == DIB BPPRLE) || (m nImageFormat == DIB JPEG) || (m nImageFormat == DIB PNG); } }: Primele patru variabile ale clasei KDIB conțin cele mai importante informații despre rastere, din care puteți obține valorile tuturor celorlalte variabile Rasterele DIB există în diferite formate de bitmap, în funcție de numărul de biți/pixel, de atributul de compresie și chiar de măștile de biți Prezența unei valori care determină în mod unic formatul bitmap va simplifica foarte mult implementarea algoritmilor grafici Din acest motiv, definim tipul enumerat DIBFormat Din definiție reiese clar că formatul BMP acceptă varietati de formate bitmap Windows NT/ DDK adoptă o abordare similară pentru definirea formatelor bitmap De exemplu, funcției EngCreateBitmap (crearea suprafeței gestionate GDI) primesc constante, cum ar fi BMF RLE, BMF BPP și BMF BPP Cu toate acestea, pe lângă structura BITMAPINFOHEADER, clasa KDIB conține multe alte câmpuri Salvarea a o duzină sau doi octeți în acest caz nu este semnificativă; viteza este mult mai importanta Instanțele clasei KDIB vor locui în memoria computerului, deci reprezintă un bitmap DIB stocat mai degrabă în memorie decât pe disc; prin urmare, structura BITMPFILEHEADER nu este necesară Variabila rBMI conține un pointer către blocul de descriere raster Variabila m pBits stochează un pointer către o matrice de pixeli bitmap Stocarea separată a pointerilor către blocul de descriere raster și matricea de pixeli permite clasei KDIB să accepte atât rasterele împachetate, cât și cele dezambalate Rasterele provin dintr-o varietate de surse - încărcare dintr-un fișier sau resursă, lipire dintr-un clipboard și chiar construirea lor programatic Clasa raster trebuie să știe dacă acești doi pointeri sunt doar pentru citire sau dacă datele la care se referă trebuie să fie eliminate din memorie atunci când instanța clasei KDIB este distrusă Pentru a face acest lucru, variabila m Flags a fost inclusă în clasă, a cărei valoare este o combinație de patru steaguri: o DIBJBMI-NEEDFREE - Pointerul sh rBMI se referă la un bloc de memorie alocat în heap care trebuie eliberat în destructor; Capitolul Înțelegerea rasterelor O DIB BMI READONLY - Pointerul t rBMI se referă la date numai în citire; Despre DIB BITS NEEDFREE - Pointerul m pBits se referă la un bloc de memorie alocat din heap, care trebuie eliberat în destructor; Despre DIB BITS READONLY - Pointerul m pB ts se referă la date numai în citire Al doilea grup de cinci variabile stochează indicatorii către tabelele de culori în format RGBTRIPLE sau RGBQUAD, numărul total de culori și numărul de culori semnificative Nu acceptăm un tabel de culori cu indici de paletă care nu fac parte din formatul DIB Doar unul dintre pointerii m pRGBTRIPLE și m pRGBQUAD poate fi non-NULL Variabila m pB tsFields indică măștile de biți (dacă este utilizată) Prima parte a clasei KDIB conține pointeri directe către antetul blocului de descriere raster, tabelul de culori și măștile de biți Al treilea grup de variabile de clasă descrie în detaliu formatul imaginii Aceasta stochează lățimea și înălțimea imaginii (întotdeauna pozitive), numărul de planuri, numărul de biți pe pixel, adâncimea culorii și dimensiunea imaginii Rețineți că în antet, înălțimea rasterului poate fi o valoare negativă dacă rasterul nu este stocat invers în memorie Din cauza înălțimii negative, apar probleme în mulți algoritmi grafici, astfel încât în clasa KDIB, înălțimea este normalizată, iar orientarea rasterului în memorie este reflectată într-una dintre variabilele grupului următor Al patrulea grup de variabile conține valori utilizate în mod obișnuit, calculate din variabilele menționate mai sus Variabila n nBPS conține numărul de octeți din șirul de scanare completat la cea mai apropiată limită DWORD Variabila m pOrigin indică la originea logică a rasterului, adică la pixelul ( , ) corespunzător primului octet al matricei de pixeli pentru un raster drept (nu inversat) Variabila m nDelta conține offset-ul dintre liniile de scanare Pentru rasterele de ordine directă, m nDelta este întotdeauna pozitiv, în caz contrar este negativ Din aceste trei variabile, puteți calcula întotdeauna rapid adresa liniei de scanare, prin care este ușor să găsiți adresa unui pixel individual Variabila independentă m nDelta poate fi folosită și pentru a stoca pasul unei suprafețe DirectDraw, care poate fi sau nu la fel cu m nBPS Clasa KDIB conține un constructor implicit simplu și un destructor virtual Metoda ReleaseDIB este responsabilă pentru eliberarea resurselor alocate pentru a reprezenta imaginea curentă În plus, definim mai multe funcții care returnează caracteristicile geometrice ale imaginii ca constante Metoda AttachDIB face cea mai mare parte a muncii de inițializare a unei clase KDIB pe baza datelor unui raster DIB împachetat sau dezambalat Metoda LoadBitmap încarcă o resursă BMP dintr-un modul Win și inițializează un obiect bitmap doar pentru citire apelând funcția AttachDIB Metoda Load-File încarcă un fișier BMP de pe disc și inițializează instanța KDIB cu un apel la AttachDIB Aceste trei metode sunt prezentate în Lista Clasa pentru lucrul cu DIB Lista Inițializarea unei clase KDIB dintr-un fișier sau o resursă BMP bool KDIB::AttachDIB(BITMAPINFO * pDIB, BYTE * pBits Indicatori int) { Dacă ( IsBadReadPtr(pDIB, sizeof(BITMAPCOREHEADER)) ) returnează false; ReleaseDIB(); m pBMI=pDIB; m Flags = steaguri: Dimensiunea DWORD = * (DWORD *) pDIB: // dimensiunea este întotdeauna DWORD int compresie; // Colectarea informațiilor din structurile antetului comutatorului bloc de descriere raster ( dimensiune ) dimensiunea casei(BITMAPCOREHEADER): { BITMAPCOREHEADER * pHeader = (BITMAPCOREHEADER *) pDIB: mjiWidth = pHeader->bcWidth; m nHeight = pHeader->bcHeight: m nPlanes = pHeader->bcPlanes; mjiBitCount = pHeader->bcBitCount; m nImageSize= : compresie = BI RGB; dacă (mjiBitCount bmiHeader; mjiWidth = pHeader->biWidth; m nHeight = pHeader->biHeight; m nPlanes = pHeader->biPlanes; m nBitCount = pHeader->biBitCount; m nImageSize= pHeader->bi Si zelmage; compresie = pHeader->biCompression; Continuare Capitolul Înțelegerea rasterelor Lista Continuare m nClrUsed = pHeader->biCIrUsed: m nClrImpt = pHeader->biCIrImportant: dacă ( m nBitCoint bm Header, CBMJNIT, m pBits m pBMI, DIB RGB COLORS); } Dacă o paletă este implicată în procesul de conversie DIB în DDB, atunci este utilizată paleta curentă selectată în contextul dispozitivului LoadBitmap În programarea Windows, hărțile de bit sunt de obicei atașate unui modul ca resursă și apoi încărcate ca DDB cu funcția LoadBitmap Funcția LoadBitmap ia doi parametri: hlnstance, mânerul modulului care conține resursa bitmap și IpBitmapName, numele resursei bitmap Dacă parametrul hlnstance este NULL, al doilea parametru trece constantele OBM BTNCORNERS, OBM SNECK etc , care definesc zeci de raster-uri standard de sistem Aceste hărți de biți sunt fie preluate direct din modulul USER dll, fie sintetizate de acest modul Dacă un identificator întreg este folosit pentru a identifica o hartă de biți într-un fișier de resurse, întregul este convertit într-un pointer într-un șir de caractere folosind macro-ul MAKEINTRESOURCE Resursele bitmap sunt stocate în module Win într-un format DIB bitmap Funcția LoadBitmap găsește o resursă bitmap, o angajează în memorie pentru a obține un handle de bitmap DIB împachetat și apoi creează un bitmap DDB care este compatibil cu modul de ecran curent Pentru hărțile de biți monocrome (adică hărțile de biți DIB al căror tabel de culori conține doar alb-negru), GDI utilizează formatul monocrom DDB în loc de formatul color care necesită multă memorie Când lucrați în modul ecran cu paletă de de culori, încărcarea imaginilor True Color și High Color are ca rezultat o calitate slabă a imaginii, deoarece aplicația nu poate controla procesul de conversie a culorilor Următorul cod încarcă bitmap-ul barei de instrumente din biblioteca BROWSEUI dll: HINSTANCE hMod = LoadLIbrary(”browseui dl ”): HBITMAP hBmp = LoadBitmap(hMod MAKEINTRES URCE( D); FreeLlbrary(hMod): Documentația Microsoft spune că pe Windows , atunci când se utilizează funcția LoadBitmap, există probleme la încărcarea bitmap-urilor mai mari de KB din cauza implementării subiacente pe biți Dacă dimensiunea resursei DIB este Rastere dependente de dispozitiv depășește KB, implementarea internă a LoadBitmap îl va converti într-o valoare deplasată la stânga de ori, ceea ce poate duce la pierderea celor mai puțin semnificativi biți ai dimensiunii Soluția este să completați resursa cu zerouri pentru a rotunji dimensiunea În schema standard de utilizare a LoadBitmap, bitmap-ul este încărcat și redat o dată, după care obiectul este șters Dacă sunteți îngrijorat de viteza programului, puteți face modificări acestei scheme Conversia DIB în DDB este lentă și DDB irosește resursele sistemului În astfel de situații, este mai rapid și „mai ieftin” să lucrezi direct cu DIB-ul Dar dacă un raster este încărcat o dată și reutilizat de mai multe ori, utilizarea DDB poate economisi timpul petrecut cu conversia formatului raster Copierea bitmap-urilor între formatele DIB și DDB Pe lângă funcțiile pentru crearea de noi rastere DDB, GDI oferă două funcții pentru copierea pixelilor între DDB și DIB Int SetDIBIts(HDC hdc hbmp hbmp UINT uStartScan UINT cScanLines CONST VOID * IpvBits CONST BITMAPINFO * Ipbmi UINT fuColorUse): Int GetDIBIts(HDC hdc HBITMAP hbmp UINT uStartScan UINT cScanLines CONST VOID * IpvBits CONST BITMAPINFO * Ipbmi UINT fuColorUse); Listele de parametri ale acestor două funcții sunt aceleași, deși documentația MSDN are nume ușor diferite Primul parametru specifică contextul dispozitivului de referință a cărui paletă ar trebui utilizată la conversia formatului de pixeli Al doilea parametru conține un mâner pentru un obiect raster existent dependent de dispozitiv Cei cinci parametri rămași definesc fragmentul bitmap-ului DIB despachetat și interpretarea tabelului său de culori Un fragment poate fi fie un raster DIB complet, fie un grup de linii de scanare adiacente O astfel de soluție este destinată în principal să economisească memorie și să afișeze treptat fragmente dintr-un raster încărcat printr-o conexiune lentă Parametrul IpvBits conține un pointer către liniile de scanare, parametrul uStartScan specifică numărul primei linii de scanare din buffer, iar parametrul cScanLines specifică numărul de linii de scanare din buffer Funcția SetDIBits convertește pixelii fragmentului DIB dat în format DDB și copiază rezultatul în DDB Funcția GetDIBits convertește pixelii din formatul DDB în formatul DIB și copiază rezultatul în bufferul de fragmente DIB Funcția SetDIBits este implementată de fapt de funcția SetDIBitsToDevice, specificând ca destinație contextul dispozitivului compatibil în care este selectată bitmap-ul DDB Procesul de conversie selectează paleta contextului specificat de parametrul hdc într-un context de dispozitiv compatibil Există mai multe moduri de a converti DIB în DDB Un bitmap DIB stocat ca resursă poate fi încărcat în DDB folosind funcția LoadBitmap Din păcate, nu aveți control asupra procesului de conversie Funcția CreateDIBitmap creează un bitmap DDB complet nou, bazat pe DIB, care este compatibil cu contextul dispozitivului dat Astfel, această caracteristică permite Capitolul Înțelegerea rasterelor un anumit grad de control asupra conversiei culorii și, în același timp, este ușor de lucrat În comparație cu LoadBitmap și CreateDIBitmap, funcția SetDIBits este mai puternică Deoarece nu întregul bitmap DIB este copiat în DDB, ci un fragment din acesta, apelantul poate folosi un buffer mai mic și poate efectua conversia în mod incremental; de asemenea, poate îmbina mai multe bitmap-uri DIB mici într-un singur bitmap DDB mare și poate gestiona formatul DDB Funcția GetDIBits este considerată a fi cea mai comună modalitate de a converti DDB în DIB Procesul de conversie a DDB în DIB nu este ușor, deoarece necesită suport pentru diferite formate DIB Funcția GetDIBits acceptă toate combinațiile DIB de codificări de culoare, formate (RGB/paletă), prezența și absența compresiei RLE într-o matrice de pixeli și câmpuri de biți Parametrul Ipbmi conține un pointer către antetul de informații al rasterului DIB, care definește formatul acestuia Cu compresia RLE, aplicația nu poate determina cu ușurință dimensiunea imaginii comprimate Funcția GetDIBits trebuie apelată de două ori La primul apel, NULL este transmis în pointerul către matricea de pixeli, la care GDI returnează dimensiunea tampon necesară La al doilea apel, tamponul alocat de dimensiunea specificată este umplut cu date de imagine Lista - arată funcția Bi tmapToDIB, care este un înveliș convenabil pentru apelarea funcției GetDIBits Funcția primește mânerul de obiect al paletei GDI utilizat pentru a construi tabelul de culori, mânerul de obiect DDB, numărul de octeți pe pixel și indicatorul de compresie DIB Funcția calculează dimensiunea DIB, alocă un buffer de dimensiunea necesară, scrie datele DDB în el și returnează un pointer către buffer Lista Funcția BitmapToDIB: Convertiți DDB în DIB BITMAPINFO * BitmapToDIB(HPALETTE hPal, // Palette for // transformări de culoare HBITMAP hBmp, // Raster DDB convertit Int nBitCount, int nCompression) // Formatul dorit { typedef struct BITMAPINFOHEADER bmiHeader; RGBQUADbmiColors[ + ]: }DIBINFO: BITMAP ddbinfo: DIBINFO dibinfo; // Obține date DDB dacă ( GetObject(hBmp, sizeof(BITMAP), & ddbinfo)== ) returnează NULL; // Populați structura BITMAPINFOHEADER // în funcție de datele de dimensiune și formatul solicitat memset(&dibinfo, , sizeof(dibinfo)): di bi info bmi Header bi Size = sizeof(BITMAPINFOHEADER); Rastere dependente de dispozitiv dlbliinfo bmlHeader biWidth = ddbinfo bmWidth; dibinfo bmiHeader biHeight = ddbinfo bmHeight; diblinfo bmlHeader biPlanes = : diblinfo bmlHeader biBitCount = nBitCount; dibinfo bmiHeader biCompression = nCompression: HDC hDC = GetDC(NULL); // Contextul ecranului dispozitivului HGDIOBJ hpalOld; dacă (hpal) hpalOld = SelectPalette(hDC, hPal FALSE); altfel hpalOld = NULL; // Cereți GDI pentru dimensiunea imaginii GetDIBIts(hDC hBmp, ddbinfo bmHeight NULL (BITMAPINFO *) & dibinfo, DIB RGB COLORS); int nlnfoSize = sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * GetDIBColorCount(dibinfo bmiHeader); int nTotalSize = nlnfoSize + GetDIBPixelSlze(dibinfo bmiHeader): BYTE * pDIB = nou BYTE[nTotalSize]; dacă (pDIB) memcpy(pDIB, & dibinfo, nlnfoSize); dacă ( ddbinfo bmHeight != GetDIBIts(hDC, hBmp, , ddbinfo bmHeight, pDIB + nlnfoSize, (BITMAPINFO *) pDIB, DIB RGB COLORS) ) { șterge[]pDIB; pDIB=NULL; } } dacă ( hpalOld ) SelectObject(hDC, hpalOld); ReleaseDC(NULL, hDC): return (BITMAPINFO *) pDIB; } Pentru a simplifica apelul, funcția BitmapToDIB nu necesită apelantului să treacă într-o structură BITMAPINFO Se creează o structură DIBINFO pe stiva cu un tabel de culori de de elemente; acest lucru este suficient pentru un raster DIB care utilizează câmpuri de biți și de culori întregi Lățimea și înălțimea DIB sunt calculate din dimensiunile DDB După ce primul apel la GetDIBIts returnează dimensiunea reală a imaginii, funcția alocă memorie pentru buffer, copiază antetul descrierii rasterului și apoi apelează GetDIBIts pentru a încărca întregul raster DIB Capitolul Înțelegerea rasterelor Funcția GetDIBits are o altă caracteristică neevidentă Dacă atribuiți doar o valoare câmpului biSize și lăsați celelalte câmpuri setate la , GDI le va popula cu biți/pixel și modul de compresie utilizat de contextul dispozitivului În acest fel, aplicația poate determina cu exactitate formatul de pixeli utilizat de contextul dispozitivului Această tehnică este utilă în special dacă aplicația trebuie să lucreze direct cu pixeli în modul video de bpp Codificarea pe biți are două subtipuri standard: - - și - - În unele situații, aplicația trebuie să cunoască formatul exact de pixeli; problema este rezolvată de funcția PixelFormat prezentată în Lista Lista Funcția PixelFormat: Specificarea formatului pixelilor contextul dispozitivului int PixelFormat (HDC hdc) { typedef struct { BITMAPINFOHEADER bmiHeader: RGBQUADbmiColors[ + ]: }DIBINFO: DIBINFO dibinfo: HBITMAP hBmp = CreateCompatibleBitmap(hdc, ); dacă (hBmp—NULL) returnează - : memsetC&dibinfo sizeof(dibinfo)): dibinfo bmiHeader biSize = sizeof(BITMAPINFOHEADER): // Primul apel pentru a obține valoarea biBitCount pentru hdc GetDIB ts(hdc hBmp, , NULL, (BITMAPINFO*) & dibinfo, DIB RGB COLORS); // Al doilea apel pentru a obține tabelul de culori sau câmpurile de biți GetDIBits(hdc, hBmp NULL, (BITMAPINFO*) & dibinfo DIB RGB COLORS): DeleteObject(hbmp); // Încercați să interpretați câmpurile de biți dacă ( dibinfo bmiHeader biBitCount-BI BITFIELDS ) { DWORD * pBitFields = (DWORD *) dibinfo bmiColors: DWORD roșu = pBitFields[O]: DWORD verde = pBitFields[l]: albastru DWORD = pBitFields[ ]: dacă ( (albastru-OxOOlF) && (verde-OxOOlF) && (roșu== x C ) ) returnează DIB RGB : else if ( (albastru—OxOOlF) && (verde— x E) && (roșu— xF ) ) returnează DIB RGB : altfel dacă ((albastru—OxOOFF) && (verde==OxFFOO) && (roșu—OxFFOOOO) ) Rastere dependente de dispozitiv returnează DIB RGB : altfel returnează - : } swltch ( dibinfo bmlHeader blBltCount ) { cazul :retur DIB BPP; cazul : returnează DIB BPP: cazul :retur DIB BPP; cazul : returnează DIB BPP: cazul : returnează DIB RGB : cazul : returnează DIBJ RGB : cazul : returnează DIB RGB : implicit: return - : } } Funcțiile SetDIBits și GetDIBits acceptă și un alt format raster GDI, care va fi discutat în secțiunea „Secțiuni DIB” Documentația (CV Q ) spune că atunci când utilizați GetDIBits pentru a converti secțiuni DIB codificate de sau biți/pixel în DIB-uri codificate de biți/pixel, tabelul de culori DIB este configurat incorect Acces direct la matricea de pixeli DDB Una dintre principalele caracteristici ale rasterelor dependente de dispozitiv este că rasterele DDB nu au un tabel de culori și pot avea un format de pixel intern unic definit de producătorul hardware Formatul monocrom este considerat a fi singurul format DDB standard Din această cauză, accesul direct la datele grafice DDB nu are prea mult sens (în special pentru hărțile de biți DDB color) Cu toate acestea, GDI oferă câteva funcții care permit unei aplicații să lucreze cu matrice de pixeli DDB: LONG GetBitmapBItsCHBITMAP hBmp LONG cbBuffer, LPVOID IpvBits): LONG SetBItmapBIts(HBITMAP hBmp, LONG cBytes, LPVOID pBits): Funcția GetBitmapBits copiază matricea de pixeli DIB în buffer-ul specificat de parametrii cbBuffer și IpvBits Dar cum să aflați dimensiunea tamponului alocat? Documentația Microsoft nu menționează că funcția GetBitmapBits returnează dimensiunea necesară a bufferului dacă dimensiunea este și indicatorul bufferului conține NULL Matricea de pixeli este copiată fără conversie de format sau culoare Funcția SetBitmapBits face opusul: copiază conținutul tamponului într-o matrice de pixeli bitmap Găsirea unei utilizări rezonabile pentru aceste două funcții nu este ușoară Una dintre opțiuni este implementarea algoritmilor eficienți pentru lucrul cu DDB fără a utiliza contexte compatibile De exemplu, puteți implementa cu ușurință inversarea pe pixel, reflexia speculară și rotațiile liniei de scanare O altă utilizare posibilă este investigarea formatului intern al DDB Funcția de mai jos scoate conținutul matricei de pixeli DDB într-o casetă de text (presupunând că avem o funcție de ieșire hex) Capitolul Înțelegerea rasterelor noua haldă HexDump) În sistemele din familia Windows NT, aproape toate adaptoarele video utilizează cadre tampon cu un format DIB cu un singur plan, astfel încât matricea lor de pixeli DDB este destul de aproape de matricea DIB Pe de altă parte, în modurile VGA standard sau pe sistemele din familia Windows , formatul DDB devine mai complicat void DumpBitmap(HWND hWnd HWITMAR hBMP) { int size = GetBitmapB ts(hBmp, , NULL); BYTE * pBuffer = nou BYTE[dimensiune]; dacă (pBuffer) GetB tmapBits(hBmp, dimensiune, pBuffer); HexDump(hWnd, pBuffer, dimensiune); șterge[]pBuffer; } } Utilizarea rasterelor DDB Rasterele dependente de dispozitiv sunt utilizate pe scară largă în programarea Windows Secțiunea anterioară a fost despre diferitele modalități de a crea un DDB și de a converti între DDB, DIB și conținutul real al unei matrice de pixeli Această secțiune discută afișarea rasterelor DDB și utilizarea lor în meniuri, bare de instrumente și așa mai departe Afișarea rasterelor DDB Deși bitmaps-urile DDB joacă un rol foarte important în programarea Windows, nu veți găsi funcții în GDI pentru a afișa direct DIB-urile Pentru a obține un DIB, o aplicație trebuie să creeze un context de dispozitiv compatibil, să selecteze un DDB în acesta și să copieze datele pixelilor din contextul dispozitivului compatibil în contextul de recepție Această schemă orientată în context este bună deoarece un raster DDB poate fi atât o sursă, cât și o destinație pentru o operațiune de ieșire În plus, puteți chiar să copiați o parte a unui DDB într-o altă parte a aceluiași bitmap DDB! Pentru comparație, este de remarcat faptul că GDI acceptă numai funcții care afișează conținutul DIB - și nicio funcție pentru afișarea conținutului DIB În GDI, problema maparii DDB este rezolvată în mod generic ca problema trimiterii unei matrice dreptunghiulare de pixeli de la un dispozitiv grafic la un alt dispozitiv grafic, fiecare dintre acestea fiind reprezentat de un handle de context al dispozitivului Astfel de operațiuni de transfer sunt denumite în mod tradițional prin abrevierea „BitBlt” din cuvintele „Bit boundary Block Transfer” Există două funcții principale de blitting în GDI: În rusă, termenul „blitting” este de obicei folosit - Notă transl Utilizarea rasterelor DDB BOOL BitBlt(HDC hdcDst Int nXDst int nYDst, int nWidth, int nHeight, HDC hdcSrc, int nXSrc, int nYSrc, DWORD dwRop); BOOL BitBlt(HDC hdcDst, int nXDst, int nYDst, int nWDst, int nHDst, HDC hdcSrc int nXSrc, int nYSrc, nWSrc, int nHSrc DWORD dwRop): Funcția BitBlt transferă un bloc dreptunghiular de pixeli de la dispozitivul sursă la dreptunghiul de destinație Dreptunghiul sursă este definit de parametrii nXSrc, nYSrc, nWidth și nHeight în sistemul de coordonate logic al contextului dispozitivului sursă Dreptunghiul de recepție este definit de parametrii nXDst, nYDst, nWidth și nHeight în sistemul de coordonate logic al contextului dispozitivului receptor Ambele contexte de dispozitiv trebuie să accepte operațiuni bitmap RC BITBLT De exemplu, dacă contextul dispozitivului sursă este un context metafișier, o încercare de a apela BitBlt va eșua deoarece contextul metafișierului nu are un cadru tampon al cărui conținut poate fi citit De asemenea, GDI nu reușește să gestioneze cazurile în care contextul original al dispozitivului are o transformare de rotație sau translație care poate transforma dreptunghiul original într-un paralelogram sau într-un dreptunghi ale cărui laturi nu sunt paralele cu axele Dacă dreptunghiurile sursă și destinație au dimensiuni diferite în sistemele de coordonate ale dispozitivului, imaginea sursă este scalată pentru a se potrivi cu poligonul de destinație În contextul dispozitivului receptor, orice transformări poate avea efect, deși transformările lumii nu sunt acceptate pe sistemele din familia Windows Ca și în cazul funcției StretchDIBits, schimbarea semnului în parametrii dreptunghiului sursă și destinație vă permite să oglindiți rasterul de-a lungul axei verticale și/sau orizontale Ultimul parametru, dwRop, definește o operație raster ternară, adică modul în care pixelul sursă, pixelul destinație și pensula sunt combinate pentru a forma o nouă valoare a pixelului sursă Deocamdată, ne vom restrânge la operația ternară SRCCOPY, în care pixelii destinației sunt pur și simplu înlocuiți cu pixelii sursei Funcția StretchBlt face aproape la fel ca și funcția BitBlt Singura diferență este că dreptunghiurile sursă și destinație sunt dimensionate independent, astfel încât funcția StretchBlt este utilizată de obicei în situațiile în care dreptunghiurile sursă și destinație au dimensiuni diferite în coordonate logice Dacă scalarea reală este necesară sau nu depinde de setarea sistemelor de coordonate logice Rearanjarea aleatorie a fragmentelor de ecran Să ne uităm la utilizarea funcțiilor BitBlt/StretchBlt cu un exemplu specific Vom scrie un program care copiază un dreptunghi de ecran selectat aleatoriu într-un alt dreptunghi selectat aleatoriu Pentru a face imaginea să pară mai strălucitoare, folosim o operație bitmap selectată aleatoriu cu o perie uniformă de culoare aleasă aleatoriu Dreptunghiul de destinație este definit cu o lățime și o înălțime negative, astfel încât dreptunghiul sursă este rotit cu ° Ca urmare a scalării, dreptunghiul de recepție este dublat în comparație cu sursa După câteva iterații, ecranul începe să arate destul de original Nu vom scrie un screen saver complet, deci codul Capitolul Înțelegerea rasterelor face doar bucle de de ori și apoi se termină cu o solicitare de redesenare a ecranului int WINAPI WlnMainCHINSTANCE hlnst INSTANŢĂ PSTR int) { HDC hDC = GetDC(NULL): int width = GetSystemMetrics(SM CXSCREEN): int height = GetSystemMetrics(SM CYSCREEN): pentru (int i= : i = bmp bmWidth ) returnează NULL; HDC hMemDCS = CreateCompatibleDC(NULL): HDC hMemDCD = CreateCompatibleDC(NULL); SelectObject(hMemDCS m hBmp): int w = GetSystemMetrics(SM CXMENUCHECK): int h = GetSystemMetrics(SM CYMENUCHECK): HBITMAP hRslt = CreateCompatibleBitmap(hMemDCS w h): dacă (hRslt) { HGDIOBJ hold = SelectObject(hMemDCD hRslt): StretchBlt(hMemDCD wh hMemDCS d*bmp bmHeight bmp bmHeight, bmp bmHeight SRCCOPY): SelectObject(hMemDCD Hold); AdaugăBitmapdd hrslt): } DeleteObject(hMemDCS): DeleteObject(hMemDCD): returnați hRSLT: } BOOL KCheckMark::SetCheckMarks(HMENU hMenu, UINT uPos UINT uFlags int nebifat int bifat) { returnează SetMenuItemBitmaps(hMenu, uPos, uFlags, GetSublmage(nebifat) GetSublmage(bifat)): Utilizarea rasterelor DDB Clasa KCheckMark încarcă un singur bitmap, constând din mai multe bitmap-uri mai mici unul lângă altul (similar bitmap-urilor utilizate în barele de instrumente) Bitmap-ul este încărcat de funcția Loadlmage, care înlocuiește pixelii de fundal cu culoarea standard a ferestrei (COLOR WINDOW) utilizând indicatorul LR LOADTRANSPARENT Culoarea implicită a ferestrei este de obicei aceeași cu culoarea de fundal a meniului, iar acest lucru ne ajută să rezolvăm problema îmbinării bitmap-ului cu fundalul meniului Cea mai mare parte a muncii utile din această clasă este realizată de funcția GetSublmage, care „decupează” un mic fragment dintr-un raster Se presupune că fragmentele sunt situate pe o singură linie, astfel încât dimensiunile lor sunt calculate după înălțimea rasterului general Funcția primește dimensiunile rasterelor utilizate ca etichete pentru comenzile de meniu și scalează fragmentele în funcție de acestea ID-ul fragmentului raster și mânerul sunt stocate într-un tabel, astfel încât să poată fi utilizate în viitor Selectarea noilor etichete în loc de atribuite sau utilizate în mod implicit este efectuată de funcția SetMenuImageItems Deoarece sistemul de operare Windows nu face copii ale bitmap-urilor, tabelul manipulator este folosit în destructorul de clase pentru a elimina obiectele bitmap Instanțele clasei KCheckMark trebuie să existe la nivel de fereastră sau aplicație, astfel încât destructorii lor să fie apelați numai atunci când bitmap-ul nu mai este utilizat Pe fig arată rezultatul utilizării bitmap-urilor pentru a proiecta unele comenzi standard de meniu Bitmap sursă încărcat din modulul browserui dll, ID resursă F* V -ZSK „F WndProc(hWnd, uMsg, wParam IParam); altfel returnează DefWindowProc(hWnd, uMsg wParam IParam); } BOOL KBackground::Atașați(HWND hWnd) { SetProp(hWnd Prop KBackground this); m dProc = (WNDPROC) SetWindowLong(hWnd GWL WNDPROC (LONG) BackGroundWindowProc): returnează m dProc!=NULL: } BOOL KBackground::Detatch(HWND hWnd) RemoveProp(hWnd PropJCBbackground): dacă ( m dProc ) returnează SetWindowLong(hWnd GWL WNDPROC (LONG) m dProc) == (LONG) BackGroundWindowProc: altfel returnează FALSE; Utilizarea rasterelor DDB Clasa KBackground definește două metode virtuale (fără a număra destructorul virtual) Metoda EraseBackground desenează fundalul ferestrei; implementarea implicită apelează pur și simplu DefWindowProc Metoda WndProc procesează toate mesajele, deși în acest caz ne interesează doar mesajul WM ERASEBKGND Subclasarea unei ferestre existente se face prin apelarea metodei Attach Fereastra este asociată cu o proprietate, a cărei valoare este un pointer către o instanță a clasei KBackground, iar funcția fereastră este suprascrisă de funcția statică BackGroundWindowProc La primirea mesajului, această funcție interogează valoarea proprietății pentru a obține pointerul this pentru instanța KBackground și apoi transmite apelul metodei sale WndProc Rețineți că nu putem stoca acest pointer în câmpul GWLJJSERDATA așa cum am făcut în clasa KWindow, deoarece fereastra subclasată ar putea fi creată de o altă parte folosind câmpul GWLJJSERDATA Nici variabilele globale nu sunt bune, pentru că vrem să folosim clasa noastră pentru a suporta mai multe ferestre în același timp, dar nu este nevoie să creăm tabele de expediere globale ca în MFC Clasa KBackground rezolvă problema generală a subclasării și interceptării mesajului WM JERASEBKGND Cu toate acestea, există diverse opțiuni pentru desenarea fundalului - linii care formează un model de rețea, umplerea zonelor închise, funcții de ieșire DIB sau DDB Aceste opțiuni sunt implementate în clase specializate care derivă din clasa generică KBackground Implementarea DDB orientată spre rezultate este prezentată în Lista Lista Clasă pentru desen de fundal cu ieșire DDB clasa KDDBBBackground : public KBackground { KDDB m DDB; int m nStyle: virtual LRESULT EraseBackground(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM IParam); public: KDDBBFondulO { m nStyle = KDDB::draw tile; } void SetStyle (stil int) { m nStyle = stil: } void SetBitmap(HMODULE hModule, int nRes) { m DDB LoadBitmap(hModule, nRes): } }: LRESULT KDDBBackground::EraseBackground(HWND hWnd UINT uMsg WPARAM wParam, LPARAM IParam) { Continuare Capitolul Înțelegerea rasterelor Lista Continuare dacă ( m DDB GetBitmap() ) { RECT rect; HDC hDC = (HDC) wParam; GetClientRect(hWnd, &rect); HRGN hRgn = CreateRectRgnlndirect(Srect); SaveDC(hDC); SelectClipRgn(hDC hRgn); DeleteObject(hRgn); m DDB Draw(hDC rect stânga rect sus rect dreapta - rect stânga, rect bottom - rect sus SRCCOPY, mjiStyle): RestoreDC(hDC - ): întoarcere ; // Procesat } altfel returnează DefWindowProc(hWnd, uMsg wParam IParam); } Pentru a încărca și afișa DDB, clasa KDDBBackground folosește clasa KDDB Acesta suprascrie metoda EraseBackground și implementează redarea în fundal în ea Utilizarea acestei clase este ușoară Tot ce trebuie să faceți este să creați o instanță a clasei KDDBBackground, să setați rasterul și stilul de afișare și apoi subclasați fereastra apelând metoda Attach Pe fig Figura prezintă rezultatele subclasării pentru o casetă de dialog, un cadru de grupare și un cadru static Caseta de dialog este umplută cu o textură de lemn, într-o casetă de grupare textura cărămizii este centrată, iar într-o casetă statică aceeași textură este scalată proporțional Și lucrul grozav este că pentru fiecare fereastră, sarcina este rezolvată cu doar trei linii de cod la procesarea mesajului WM INITDIALOG // KDDBBBackground întreg; // KDDBBBackground groupbox: // KDDBBcadru de fundal; întreg SetBitmap(m hInstance IDB PAPER ); întreg SetStyle(KDDB::draw tile); întreg Atașați(hWnd): groupbox SetBitmap(m hInstance, IDB BRICK ); groupbox SetStyle(KDDB::draw center); groupbox Attach(GetDlgItem(hWnd IDC GROUPBOX)); frame SetBitmap(m hInstance IDB BRICK ); frame SetStyle(KDDB::draw stretchprop); frame Attach(GetDlgItem(hWnd, IDC FRAME)); Utilizarea rasterelor DDB Orez Utilizarea clasei KDDBBackground într-o casetă de dialog Secțiuni DIB Am analizat cele două formate de bitmap principale acceptate de GDI: hărți de biți independente de dispozitiv (DIB) și hărți de biți dependente de dispozitiv (DDB) Rasterele DIB pot exista într-o varietate de formate de culoare standard, în funcție de situație DDB-rasterele, din motive practice, sunt fie monocrome, fie formatul lor de culoare se potrivește cu formatul dispozitivului Instrumentele GDI vă permit să desenați atât DIB, cât și DDB, totuși GDI acceptă doar desenarea pe o hartă de biți DDB selectată într-un context de dispozitiv compatibil și nu acceptă desenarea pe un DIB Rasterele DIB sunt bune, deoarece stocarea lor este organizată la nivel de aplicație, astfel încât aplicația poate funcționa direct cu tabelul de culori și matricea de pixeli, dar nu vă puteți baza pe GDI pentru a vă ajuta să creați DIB-uri Avantajele rasterelor DDB sunt că pot fi desenate folosind instrumente GDI; pe de altă parte, nu aveți acces direct la reprezentarea internă a DDB deoarece este gestionată de GDI Deoarece rasterele DDB sunt stocate în memoria sistemului, există limite atât pentru dimensiunea maximă a unui singur raster DDB, cât și pentru dimensiunea totală a tuturor rasterelor DDB de pe sistem Pe de altă parte, stocarea DIB este organizată de aplicație, astfel încât dimensiunea DIB este limitată doar de cantitatea spațiului de adrese virtuale al procesului și de spațiul liber pe disc alocat fișierului de paginare a sistemului Apare o întrebare firească: există un tip raster care are toate avantajele DIB și DDB? Da este Acesta este un nou tip de raster acceptat în secțiunile Win GDI API - DIB Termenul „secțiune DIB” pare destul de ciudat Probabil că programatorul care a lucrat la implementare nu s-a obosit să ridice un nume normal, iar specialiștii în documentare habar nu aveau despre ce este vorba Documentația Microsoft definește o secțiune DIB ca un bitmap DIB în care o aplicație poate scrie direct date Dar aplicațiile din zilele Windows scriu date direct în DIB și fără secțiuni DIB La fel Capitolul Înțelegerea rasterelor documentația susține că o secțiune DIB face parte dintr-un DIB, dar de fapt o secțiune DIB conține întotdeauna un bitmap DIB complet Pentru a evita alte neînțelegeri, merită să dați o definiție normală O secțiune DIB este un bitmap DIB care oferă acces direct de citire/scriere atât din aplicație, cât și din GDI Vă întrebați, ce legătură are „secțiunea” cu asta? Acest lucru se datorează faptului că matricea de pixeli a unei secțiuni DIB poate fi stocată într-un fișier mapat în memorie, care se numește „secțiune” în mediul de dezvoltare a sistemului de operare Windows Chiar dacă o secțiune DIB nu se află într-un fișier mapat în memorie, matricea sa de pixeli este stocată în memoria virtuală, care poate fi schimbată în fișierul de schimb de sistem Probabil ar fi mai corect să numiți secțiunile DIB „rastere DIB cu acces dublu” O secțiune DIB, ca un bitmap specific dispozitivului, este un obiect GDI Când este creată o secțiune DIB, GDI returnează un handle de obiect secțiune DIB de tipul familiar HBITMAP Dar, spre deosebire de DDB, GDI returnează și adresa matricei de pixeli a secțiunii DIB, astfel încât aplicația să poată lucra direct cu datele grafice Când a terminat cu o secțiune DIB, aplicația trebuie să apeleze funcția DeleteObject pentru a elibera resursele asociate acesteia Când lucrați cu secțiuni DIB, sunt utilizate aceleași funcții API ca și atunci când lucrați cu DDB, așa că au apărut doar trei funcții noi care acceptă secțiuni DIB la nivel de API: HWITMAP CreateDIBSection(HDC hDC, CONST BITMAPINFO *pbmi, UINT iUsage, PVOID * ppvBits HANDLE hSection, DWORD dwOffset); UINT GetDIBColorTable(HDC hDC UINT uStartIndex UINT cEntrles RGBQUAD*pColors): UINT SetDIBColorTable(HDC hDC UINT uStartIndex, UINT cEntrles, CONST RGBQUAD * pColors): typedef struct tabDIBSection { BITMAP dsBm: BITMAPINFOHEADER dsBmih; DWORD dsBitfields[ ]; HANDLE dshSection; DWORD dsoffset; } DIBSECȚIE: CreateDIBSection Funcția CreateDIBSection creează un obiect secțiune DIB Dintre parametrii acestei funcții, primii trei sunt cei mai importanți Primul parametru este un pointer către contextul dispozitivului de referință Parametrul pbmi indică o structură BITMAPINFO care conține un handle de bitmap, măști de biți și un tabel de culori Parametrul IUsage spune dacă tabelul de culori conține valori RGB sau indici de paletă Dacă valoarea este DIB PAL COLORS, este utilizată paleta logică selectată în prezent în hdc Deci, primii trei parametri definesc complet dimensiunile, formatul pixelilor și tabelul de culori al secțiunii DIB Al patrulea parametru, ppvBits, conține adresa unui re-pointer în care GDI setează adresa matricei de pixeli a secțiunii DIB Utilizarea rasterelor DDB Ultimii doi parametri oferă alocarea memoriei și inițializarea matricei de pixeli folosind un bloc din obiectul fișier mapat în memorie Parametrul hSection conține mânerul pentru obiectul fișier mapat în memorie obținut din apelul la CreateFi eMapri ng Rețineți numele parametrului: așa cum sa menționat mai sus, obiectul fișier mapat în memorie este numit și „obiect secțiune” Acesta este probabil unul dintre motivele apariției termenului ciudat „secțiune DIB” Parametrului dwOffset i se transmite offset-ul matricei de pixeli din fișierul randat Funcția CreateDIBSection returnează două valori — un mâner de obiect secțiune DIB (valoarea de returnare a funcției) și un pointer către o matrice de pixeli (parametru ppvBits) Deși parametrii funcției CreateDIBSection arată destul de complicat, aplicațiile se concentrează de obicei pe al doilea parametru, un pointer către o structură BITMAPINFO Cu alte cuvinte, pentru a crea o secțiune DIB, trebuie să specificați lățimea, înălțimea, biți/pixel, tipul de compresie, măștile de biți și tabelul de culori GDI nu acceptă toate formatele DIB valide pentru secțiunile DIB, deoarece o secțiune DIB trebuie să fie atât citibilă, cât și inscripționabilă (ieșită) Din acest motiv, GDI acceptă numai formatul DIB necomprimat pentru secțiunile DIB Nu este posibilă crearea unei secțiuni DIB cu tipul de compresie BI RLE , BI RLE , BI PNG sau BIJPEG Pentru a gestiona secțiunea DIB, GDI alocă un bloc de memorie care stochează antetul blocului de descriere raster, măștile de biți și tabelul de culori Aceste date sunt gestionate de GDI și nu pot fi manipulate direct de aplicație Desigur, GDI își rezervă o intrare în tabelul de obiecte GDI care leagă structura internă de date GDI la secțiunea DIB Există o corespondență unu-la-unu între un handle de obiect GDI și o intrare de tabel de obiect GDI În acest sens, secțiunile DIB sunt similare cu rasterele DDB, dar diferă de rasterele DIB, care nu sunt gestionate de GDI Dacă secțiunea DIB nu este creată pe un obiect fișier mapat în memorie, GDI alocă matricea de pixeli din memoria virtuală a aplicației și returnează apelantului un pointer către aceasta Observați diferențele dintre schemele de alocare a memoriei pentru rasterele DDB și secțiunile DIB Pe sistemele din familia Windows x, memoria pentru matricea de pixeli DDB este alocată din heap-ul GDI, iar pe sistemele din familia Windows NT este alocată din pool-ul paginat în modul kernel În ambele cazuri, sunt utilizate resurse limitate la nivelul întregului sistem, iar aplicația nu are acces direct la matricea de pixeli Pe de altă parte, matricea de pixeli DIB este creată în spațiul de memorie virtual al aplicației curente, limitat doar de spațiul de memorie virtual al aplicației și spațiul liber pe disc, iar programele de aplicație pot accesa această memorie direct Pixelii din matricea alocată sunt într-o stare nedeterminată, ca într-un raster DDB neinițializat De asemenea, ar trebui să acordați atenție faptului că memoria este alocată din spațiul virtual al aplicației și nu din heap-ul de sistem Deși heap-ul de sistem este creat într-un spațiu de adrese virtuale, folosește un mecanism de alocare secundar care îmbunătățește eficiența creării unui număr mare de obiecte mici Memoria din spațiul virtual este alocată în blocuri, a căror dimensiune este un multiplu al dimensiunii paginii; pe procesoare Capitolul Înțelegerea rasterelor Intel această valoare este de KB Experimentele au arătat că GDI alocă memorie pentru secțiuni DIB în blocuri de de kiloocteți Când treceți un handle de obiect fișier mapat în memorie valid, parametrul dwOffset trebuie să fie un multiplu al DWORD Având în vedere structura BITMAPINFO, GDI poate calcula dimensiunea matricei de pixeli Cunoscând mânerul, decalajul și lungimea obiectului fișierului mapat, GDI poate apela funcția MapViewOfFIle pentru a mapa blocul de date al fișierului la spațiul virtual al aplicației Dacă datele din fișier sunt conforme cu formatul matricei de pixeli, secțiunea DIB este inițializată complet fără alocarea de memorie pentru matricea de pixeli și, eventual, copierea datelor de suprasarcină Acest lucru sugerează că o secțiune DIB poate fi creată dintr-un fișier BMP mapat în memorie Din păcate, această caracteristică nu este acceptată deoarece funcției CreateDIBSection trebuie să i se transmită un pointer către un bloc de memorie aliniat la DWORD Dimensiunea structurii BITMAPFILEHEADER este de octeți, iar dimensiunea structurii BITMAPINFO este întotdeauna un multiplu al DWORD; astfel, matricea de pixeli dintr-un fișier BMP nu este întotdeauna aliniată la o limită DWORD Dacă formatul fișierului mapat în memorie nu se potrivește cu formatul matricei de pixeli, ultimii doi parametri oferă doar un mijloc alternativ de gestionare a memoriei De ce oferă Microsoft această caracteristică? La urma urmei, fiecare octet de memorie este încă stocat pe disc - dacă nu în fișierul specificat de aplicație, atunci în fișierul de paginare a sistemului? Prin trecerea unui obiect fișier mapat în memorie la funcția CreateDIBSection, o aplicație poate specifica unde ar trebui să fie stocat fișierul și dacă ar trebui să fie partajat între mai multe procese Să presupunem că pe computerul tău fișierul de paginare a sistemului este stocat pe hard disk-ul C:, care are doar MB de spațiu liber Editorul grafic redă imaginea la culoare de de biți, rezoluție de dpi și dimensiunea întregii pagini; pentru a face acest lucru, trebuie să creeze o secțiune DIB de MB Dacă editorul este suficient de inteligent, el va vedea că există MB de spațiu liber pe hard disk D:, așa că fișierul afișat trebuie creat pe unitatea D: și transmis atunci când este apelat CreateDIBSection Editorul va gestiona acum patru imagini mari Clasă pentru lucrul cu secțiuni DIB Pentru confortul lucrului cu secțiuni DIB, acestea ar trebui să fie emise ca o clasă separată Din fericire, majoritatea codului poate fi împrumutat din clasele KDIB și KDDB (de fapt, clasa noastră de secțiune DIB va fi derivată din aceste clase) Clasa pentru lucrul cu secțiuni DIB este prezentată în Listarea Lista Clasă pentru lucrul cu secțiuni DIB clasa KDIBSecțiune : KDIB public KDDB public { public: KDIBSection() Utilizarea rasterelor DDB } virtual -KDIBSection } BOOL CreateDIBSection(HDC hDC, CONST BITMAPINFO * pBMI UINT IUsage, HANDLE hSection DWORD dwOffset); UINT GetColorTable(void): UINT SetColorTable(void); void DecodeDIBSectionFormat(TCHAR desp[]); void KDIBSection:;DecodeDIBSectionFormat(TCHAR desp[]) { DIBSECȚIE dibsec: if ( GetObject(mJiBitmap, sizeof(DIBSECTION) & dibsec) ) { KDIB:;DecodeDIBFormat(desp): tcscat(desp, T(" ")): DecodeDDB(GetBitmap(), desp + tcslen(desp)): } altfel tcscpy(desp T("Secțiunea DIB nevalidă")); } BOOL KDIBSection::CreateDIBSection(HDC hDC CONST BITMAPINFO * pBMI UINT IUsage HANDLE hSection DWORD dwOffset) { PVOID pBits = NULL: HBITMAP hBmp = ::CreateDIBSection(hDC pBMI iUsage & pBits hSection dwOffset): dacă (hBmp) { ReleaseDDB(): // Eliberează obiectul anterior ReleaseDIB(); mJiBitmap=hBmp: int nColor = GetDIBColorCount(pBMI->bmiHeader): int nSize = sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * nColor: BITMAPINFO * pDIB = (BITMAPINFO *) BYTE nou[nSize]: dacă (pDIB==NULL) returnează FALSE; memcpy(pDIB, pBMI, nSize): // Copiați antetul // și tabelul de culori AttachDIB(pDIB (PBYTE) pBits DIB BMI NEEDFREE); Continuare & Capitolul Înțelegerea rasterelor Lista Continuare GetColorTableO; returnează TRUE; } altfel returnează FALSE; } Clasa KDIBSection nu conține nicio variabilă proprie, deoarece folosește variabilele claselor KDDB și KDIB O instanță a clasei KDIBSection are capabilitățile atât ale unei instanțe KDDB, cât și ale unei instanțe KDIB Astfel, într-o secțiune DIB inițializată, puteți desena folosind instrumentele GDI folosind metodele clasei KDDB și puteți lucra direct cu matricea sa de pixeli folosind metodele clasei KDIB Codul principal al acestei clase se află în funcția CreateDIBSection, care creează o secțiune DIB Această funcție numește funcția GDI cu același nume Dacă apelul a avut succes, funcția copiază structura BITMAPINFO și populează noul tabel de culori; apoi este apelată funcția DIB::AttachDIB, care inițializează variabilele clasei KDIB Vă rugăm să rețineți că ne limităm la eliberarea noii structuri BITMAPINFO; destructorul clasei KDDB apelează DeleteObject cu un handle de secțiune DIB, care eliberează matricea de pixeli alocată de GDI Funcțiile GetObjectType și GetObject pentru secțiunea DIB Rasterele DDB și secțiunile DIB aparțin categoriei generale a obiectelor GDI, dar, desigur, există diferențe fundamentale între ele Cu doar un handle de obiect GDI, este greu de spus dacă este un bitmap DDB sau o secțiune DIB Pentru secțiunile DIB, funcția GetObjectType returnează același OBJ BITMAP( ); funcția GetObject(hBitmap, , NULL) returnează întotdeauna sizeof(BITMAP), iar funcția GetObject(hBitmap, sizeof(BITMAP), &bmp) reușește întotdeauna și populează structura BITMAP O secțiune DIB poate fi distinsă de un DDB în două moduri În primul rând, structura BITMAP returnată de GetObject conține un pointer valid către o matrice de pixeli După cum sa menționat mai sus, pentru DDB, adresa matricei de pixeli nu este transmisă aplicației, astfel încât câmpul bmBits este întotdeauna NULL Pentru secțiunile DIB, acest câmp este același cu valoarea returnată de CreateDIBSection în parametrul ppvBits În al doilea rând, GetObject poate returna o structură DIBSection dacă parametrul cbBuffer este setat la sizeof(DISBSECTION) și dimensiunea buffer-ului indicat de IpvObjects este suficient de mare pentru a menține structura DIBSection Structura DIBSection conține informații despre secțiunea DIB pe care GDI o oferă aplicațiilor Primul câmp conține structura BITMAP, care descrie secțiunea DIB din partea DDB Al doilea câmp conține o structură BITMAPINFOHEADER care descrie dimensiunea și formatul de culoare al DIB Rețineți că structura BITMAPV HEADER sau BITMAPV HEADER poate fi, de asemenea, utilizată Probabil, structurile DIBSECTI NV și DIB -SECTI NV ar fi trebuit definite la nivelul GDI Câmpul dsBitFields conține o matrice de măști de trei biți utilizate în modurile pe și de biți (modurile BI RGB și BI BITFIELDS) Dupa parerea lor Utilizarea rasterelor DDB puteți determina formatul actual de pixeli în modul de codare de bpp Dacă creați o secțiune BI RGB DIB pe biți, verificați câmpul dsBitFields din structura DIBSection pentru a vedea dacă formatul pixelilor este - - sau - - Ultimele două câmpuri sunt pentru crearea secțiunilor DIB bazate pe obiectul fișier mapat în memorie Valorile lor sunt aceleași cu parametrii trecuți la apelarea CreateDIBSection GetDIBColorTable și SetDIBColorTable Secțiunea DIB nu este un raster DIB complet, deoarece aplicația nu are acces direct la tabelul de culori, așa cum ar face cu tabelul de culori DIB Tabelul de culori al unei secțiuni DIB este controlat de GDI, iar aplicația funcționează cu acesta numai prin funcțiile GetDIBColorTable/SetDIBColorTable Aceasta ridică întrebarea: de ce o aplicație trebuie să acceseze tabelul de culori al unei secțiuni DIB dacă l-a furnizat deja la crearea secțiunii DIB cu funcția CreateDIBSection? Există cel puțin două motive bune În primul rând, dacă parametrul iUsage a fost setat la DIB PAL COLORS când a fost apelată funcția CreateDIBSection, aplicația funcționează numai cu indici de paletă logică, nu cu tabelul de culori RGB Dacă o aplicație dorește să stocheze o secțiune DIB într-un fișier BMP, are nevoie de un tabel de culori RGB normal În al doilea rând, mulți algoritmi grafici (de exemplu, ajustarea nuanței, luminozității și saturației unui raster sau convertirea acestuia în tonuri de gri) sunt implementați prin operațiuni cu tabelul de culori a imaginii Pentru a face acest lucru, aplicația efectuează manipulările necesare cu tabelul de culori RGB și returnează noua sa stare Funcția GetDIBColorTable returnează tabelul de culori RGB pentru o secțiune DIB Primului parametru al funcției i se transmite un context de dispozitiv compatibil în care ar trebui să fie selectată secțiunea DIB Parametrii uStartIndex și cEntries oferă poziția de pornire și numărul de elemente de copiat Parametrul pColors indică un buffer pentru scrierea tabelului de culori ca o matrice de structuri RGBQUAD Valoarea returnată a funcției determină numărul de elemente copiate; este un semn al unei erori Funcția SetDIBColor populează tabelul de culori al unei secțiuni DIB cu date dintr-un tabel furnizat de aplicație Este apelat cu aceiași parametri și returnează numărul de elemente copiate Mai jos sunt funcțiile relevante ale clasei KDIBSection Rețineți că folosim același context de dispozitiv compatibil care a fost folosit pentru a reda bitmap-ul, iar tabelul de culori al secțiunii DIB este stocat în variabila KDIB: :m pRGBQUAD // Copiați tabelul de culori ale secțiunii DIB în tabelul de culori DIB UINT KDIBSection::GetColorTable(void) { int lățime înălţime: Dacă ( (GetDepth()> ) || ! Pregătiți(l dth, înălțime) ) // Creați un compatibil // contextul dispozitivului returnează : returnează GetDIBColorTable(m hMemDC mjiClrUsed, m pRGBQUAD): Capitolul Înțelegerea rasterelor // Copiați tabelul de culori DIB în tabelul de culori al secțiunii DIB UINT KDIBSection::SetColorTable(void) Int-width, helght: if ((GetDepth()> ) || ! Prepare(width, helght) ) // Creare compatibil // contextul dispozitivului returnează ; returnează SetDIBColorTable(mJiMemDC , mjiClrUsed, m pRGBQUAD): } Utilizarea secțiunilor DIB: Ieșire independentă de dispozitiv Secțiunile DIB au mai multe avantaje față de DIB și DDB О Ieșire dependentă de hardware prin intermediul GDI GDI nu oferă prea mult ajutor în construirea DIB-urilor DDB acceptă doar un format de culoare compatibil cu modul actual de ecran Dacă o aplicație grafică dorește să implementeze o ieșire de ecran codificată pe de biți, biți/pixel folosind GDI, poate face acest lucru numai folosind o secțiune DIB O combinație de ieșire GDI cu acces direct la o serie de pixeli Doar secțiunile DIB acceptă ieșire GDI simultană cu acces direct la matricea de pixeli în aplicații Fără secțiuni DIB, ar trebui să creați DIBhDDBh și să treceți pixeli între ei cu funcțiile GetDIBits și SetDIBits О Schemă flexibilă de gestionare a memoriei Rasterele DDB sunt create în memoria sistemului, în timp ce memoria secțiunii DIB este alocată în spațiul de adrese virtuale al aplicației sau într-un fișier mapat în memorie Dimensiunea unei secțiuni DIB este limitată doar de cantitatea de spațiu de adrese virtuale și de spațiul liber pe disc De exemplu, dacă spațiul pe disc permite, puteți crea un DIB color de MB x pe de biți Nu este posibil să se creeze un DDB de această dimensiune deoarece pe sistemele din familia NT dimensiunea maximă a DDB este de MB, iar pe sistemele din familia Windows este de MB De asemenea, secțiunile DIB vă permit să creați mai multe rastere în același timp Gestionarea memoriei DIB este mai flexibilă De exemplu, rasterele DIB pot locui în secțiunea de resurse numai pentru citire a unui executabil Să ne uităm la implementarea ieșirii independente de dispozitiv cu un exemplu specific și să revenim la exemplul de salvare a ecranului De data aceasta dorim să stocăm conținutul ferestrei într-un bitmap DIB de de biți Desigur, conținutul ferestrei poate fi stocat într-un bitmap DDB și apoi convertit într-un bitmap DIB de de biți, dar vrem să facem altceva - și anume, să desenăm un chenar tridimensional și să etichetăm imaginea Când lucrați cu DDB în modul ecran cu culoare pe biți, ar fi foarte dificil să faceți acest lucru - tranzițiile netede ale culorii cadrului de volum sunt slab reprezentate într-un raster DDB de biți Utilizarea rasterelor DDB Pe de altă parte, dacă decideți să creați un cadru într-un bitmap DIB de de biți, GDI nu vă va ajuta Pe de altă parte, vă puteți descurca cu o secțiune DIB pe de biți Toată ieșirea se va face prin intermediul GDI, iar apoi imaginea rezultată poate fi salvată într-un fișier BMP Funcțiile SaveWindow (salvarea conținutului ferestrei) și Frame D (desenarea unui cadru tridimensional) sunt prezentate în Lista Lista Salvarea unei ferestre și construirea unui cadru într-o secțiune DIB BOOL SaveWindow(HWND hWnd, bool bClient, int nFrame, COLORREF crFrame) { RECTwnd; dacă (bClient) { if ( ! GetClientRect(hWnd, & wnd) ) returnează FALSE; altfel { if ( ! GetWindowRect(hWnd, & wnd) ) returnează FALSE; KBitmapInfo bmi; KDIBSection dibsec; bmi SetFormat(wnd right - wnd left + nFrame ★ , wnd bottom - wnd top + nFrame * , BI RGB); dacă ( dibsec CreateDIBSection(NULL, bmi GetBMIO DIB RGB COLORS NULL, NULL) ) { int lățime înălţime; dibsec Prepare(latime, inaltime); // Creați compatibil // contextul dispozitivului, // selectează dibsec în el dacă (nFrame) { Frame(dibsec m hMemDC nFrame, crFrame, , , lățime, înălțime); Titlu TCHAR[ ]; GetWindowText(hWnd Titlu sizeof(Title)/sizeof(TitleLOJ)): SetBkMode(dibsec m hMemDC, TRANSPARENT); SetTextColor(dibsec m hMemDC, RGB(OxFF, OxFF, OxFF)); TextOut(dibsec m hMemDC nFrame (nFrame- )/ , Titlu, tcslen(Titlu)); HDC hDC; dacă (bClient) hDC = GetDC(hWnd): Capitolul Înțelegerea rasterelor Lista Continuare else hDC = GetWindowDC(hWnd); // Copiați conținutul ecranului în secțiunea DIB BitBlt(dibsec m hMemDC, nFrame, nFrame width - nFrame * , height - nFrame * , hDC, SRCCOPY); ReleaseDCchWnd,hDC); returnează dibsec SaveFile(NULL); } returnează FALSE; void Frame D(HDC hDC, int nFrame, COLORREF crFrame, int stânga, int sus int dreapta, int jos) { int red = GetRValue(crFrame); int green = GetGValue(crFrame); int albastru = GetBValue(crFrame); RECT rect = { stânga, sus, dreapta, jos }; pentru (int i= ; i ) roșu = ; dacă (verde> ) verde = ; dacă (albastru> ) albastru - ; ): // Mai puțin Funcția SaveWindow ia patru parametri Parametrul hWnd conține mânerul ferestrei, parametrul bClient specifică partea de păstrat (întreaga fereastră sau zonă client), parametrul nFrame conține lățimea cadrului adăugat, iar parametrul crFrame specifică culoarea cadrului Funcția pregătește o structură BITMAPINFO pentru o secțiune DIB pe de biți folosind clasa simplă KBi tmaplnfo pentru a inițializa BITMAPINFO O instanță a KDIBSection este creată pe stivă După crearea unei secțiuni DIB, funcția SaveWindow creează un context compatibil și selectează o secțiune DIB din acesta Acum putem apela funcția Frame D pentru a desena cadrul, a afișa legenda cu textul din bara de titlu și, în final, Utilizarea rasterelor DDB copiați pixeli din contextul dispozitivului de pe ecran în centrul secțiunii DIB Programul salvează apoi secțiunea DIB într-un fișier BMP apelând metoda KDIB::SaveFile Un cadru tridimensional este construit din dreptunghiuri înalte de un pixel, a căror culoare se întunecă treptat și, începând de la mijlocul cadrului, se luminează, ceea ce creează iluzia unui cadru semicircular Un exemplu este prezentat în fig Orez Zona client salvată într-un cadru Următorul exemplu arată cum să utilizați GDI pentru a ieși într-o secțiune DIB Accesul direct la o serie de pixeli este organizat în același mod în care se face în DIB Consultați capitolul următor pentru mai multe informații Utilizarea secțiunilor DIB: Ieșire de înaltă rezoluție Alocarea memoriei pentru stocarea secțiunilor DIB în spațiul de adrese în modul utilizator vă permite să lucrați cu imagini care sunt mult mai mari decât atunci când utilizați DDB Abilitatea de a crea secțiuni DIB pe baza unui mâner de fișier mapat în memorie simplifică controlul asupra plasării datelor pe disc și în memorie Aceste două caracteristici sunt adesea folosite în editorii grafici și procesoarele software de imagine raster (Raster Image Processor, RIP) Procesorul de imagini raster preia un document scris în limbajul de descriere a paginii și îl convertește într-o imagine bitmap de înaltă rezoluție, care, după procesarea în tonuri de gri, este transferată la o imprimantă de înaltă rezoluție De exemplu, Ghostscript poate fi considerat ca un procesor software RIP - Ghost-script preia un document PostScript și îl redă ca bitmap la diferite rezoluții În această secțiune, vom scrie un procesor software RIP simplu bazat pe utilizarea secțiunilor DIB Desigur, documentele PostScript sunt prea complexe pentru astfel de exemple, dar vom apela la ajutorul GDI Capitolul Înțelegerea rasterelor și profitați de un alt instrument expresiv, util și partajat, Windows Enhanced Metafiles (EMF) Sarcina noastră este să creăm un fișier mapat în memorie, din care va fi creată o secțiune DIB de înaltă rezoluție, apoi să redam fișierul EMF din această secțiune DIB Când redarea este completă, eliminăm secțiunea DIB, închidem fișierul și obținem o reprezentare bitmap de înaltă rezoluție a fișierului EMF Principala dificultate vine din faptul că funcția CreateDIBSection necesită ca offset-ul matricei de pixeli să fie un multiplu al DWORD Fișierele BMP nu îndeplinesc această cerință, deoarece matricele lor de pixeli nu încep niciodată la o limită DWORD Vom lua o soluție și vom folosi formatul grafic Targa pe de biți, care conține un antet foarte simplu cu lungime reglabilă și acceptă matrice de pixeli RGB necomprimate în format de de biți Lista - arată clasa KTagda pentru lucrul cu secțiuni DIB în formatul grafic Targa pe de biți Lista Lucrul cu secțiuni DIB folosind fișiere mapate în memorie clasa KDIBSection : KDIBSection public { #pragma pack(push l) typedef struct { BYTE IDLength: // : Lungimea șirului de identificare BYTE CoMapType: // = fără tabel BYTE ImgType; // = TGA RGB index WORD; // index al primului element al tabelului de culori WORD Lungime: // numărul de elemente din tabelul de culori BYTECoSize; // dimensiunea elementului de tabel de culori WORD X Org: // WORD Y Org: // A WORD Lățime: // lățime WORD Înălțime: // E înălțime BYTE PixelSize: // Dimensiune de pixeli BYTE AttBits: // charID[ ]; // substituent pentru a se asigura că ImageHeader este aliniat la // limita DWORD } ImageHeader; #pragma pack(pop) MÂNER m hF e; HANDLE m hFileMapping: public: Ktarga () { m hFile = INVALID HANDLE VALUE; m hFileMapping = INVALID HANDLE VALUE; }; virtual ~KTarga () Utilizarea rasterelor DDB LansareDDBO: LansareDIBO: Dacă ( m hFileMapping!=INVALID HANDLE VALUE ) CloseHandle(m hFileMapping): if ( m hFile != INVALID HANDLE VALUE ) CloseHandle(m hFile); BOOL Lățimea creată, înălțimea int, const TCHAR * nume fișier); BOOL KTarga ::Create (lățime int înălțime int const TCHAR * pFileName) { if ( width & ) // Ocoliți problemele de compatibilitate TGA returnează FALSE: ImageHeader tgaheader: memset(& tgaheader, sizeof(tgaheader)): tgaheader IDLength = sizeof(tgaheader ID): tgaheader ImgType = : tgaheader width = lățime: tgaheader height = înălțime: tgaheader PixelSize = ; strcpy(tgaheader ID, „BitmapShop”): m hFile = CreateFile(pFileName GENERIC WRITE | GENERIC READ, FILE SHARE READ | FILE SHARE WRITE, NUL CREATE ALWAYS, FILE ATTRIBUTE NORMAL NUL): if ( m hFile==INVALID HANDLE VALUE ) returnează FALSE: int imagine size = (lățime* + )/ * * înălțime: m hFileMapping = CreateFileMapping(m hFile NULL PAGE READWRITE, sizeof(tgaheader) + imagesize, NULL): if ( m hFileMapping==INVALID HANDLE VALUE ) returnează FALSE: DWORD dwWritten=NULL: WriteFile(m hFile și tgaheader, sizeof(tgaheader) &dwWritten, NULL): SetFilePointer(m hFile, sizeof(tgaheader) + imagesize, , FILE BEGIN): SetEndOfFile(m hFile): KBitmapInfo bmi: bmi SetFormat(width height , BI RGB): returnează CreateDIBSection(NULL, bmi GetBMI() DIB RGB COLORS, m hFileMapping, sizeof(tgaheader)): Capitolul Înțelegerea rasterelor Clasa KTarga este definită pentru a deriva din clasa KDIBSection Conține două variabile noi pentru stocarea mânerelor de fișiere și maparea fișierelor Metoda principală a clasei este metoda Create, când este apelată, lățimea, înălțimea și numele fișierului sunt transmise Funcția creează obiecte de mapare a fișierelor și fișierelor, populează un antet în format grafic Targa de de octeți și creează o secțiune DIB folosind obiectul de mapare a fișierelor Deoarece antetul are de octeți, offset-ul matricei de pixeli este , un multiplu al DWORD Rețineți că fișierul trebuie creat cu acces public de citire/scriere, iar maparea fișierului trebuie să aibă și acces de citire/scriere; în caz contrar, încercările de a crea o secțiune DIB sau de ieșire într-un fișier vor eșua Fișierul și obiectele de mapare a fișierelor sunt închise în destructor după ce obiectul secțiunii DIB este șters (în ReleaseDDB) Metafișierele îmbunătățite (EMF) sunt descrise în Capitolul Pentru moment, este suficient să ne amintim că un fișier EMF este o secvență scrisă de comenzi GDI care este ușor de procesat și redat Următoarea funcție folosește clasa KTagda pentru a reda un fișier EMF BOOL RenderEMF(HENHMETAFILE hemf, Int lățime, int înălțime, const TCHAR*tgaFileName) { KTarga targa; int w = (lățimea+ )/ * ; // Asigurați-vă că valoarea este un multiplu de if ( targa Create(l înălțime, tgaFileName) ) { targa Prepare(l, inaltime): BitBlt(targa mJiMemDC , lățime înălțime NULL ALB: // Ștergeți secțiunea DIB RECT rect = { latime, inaltime }; returnează PIayEnhMetaFileCtarga mJiMemDC hemf &rect); } returnează FALSE: } Funcția RenderEMF primește un mâner EMF, lățimea și înălțimea imaginii randate și numele fișierului grafic Acesta creează o instanță a clasei KTagda pe stivă, o inițializează, umple secțiunea DIB cu culoare albă și apelează funcția PlayEnhMetaFile pentru a reda obiectul EMF din secțiunea DIB Ceea ce rămâne este să scrieți codul de interfață pentru a selecta fișierul EMF de intrare, numele fișierului de ieșire Targa și scala de redare Fișierele EMF sunt redate proporțional cu aceeași scară pe axele x și y Pentru verificare, am folosit un fișier EMF de de kiloocteți care conține un desen complex la o scară de % Dimensiunea originală a imaginii a fost de x pixeli; la scară de % a ajuns la x pixeli O secțiune DIB cu coduri de culoare pe de biți are MB În ceea ce privește dimensiunile imaginii, această lucrare de imprimare este aproape de un document de dpi de pagină întreagă Rezultate Rezultate Acest capitol a discutat cele trei tipuri de rastere acceptate de GDI — rastere independente de dispozitiv (DIB), rastere dependente de dispozitiv (DDB) și secțiuni DIB Atenția principală a fost acordată creării, transformării, afișarii și aplicării simple a acestor tipuri de rastere, precum și diferențelor dintre ele Rasterele sunt un subiect atât de serios încât descrierea sa este împărțită în trei capitole Capitolul discută aspectele non-triviale și interesante ale utilizării bitmap-urilor: operațiuni bitmap, transparență, acces direct la pixeli și mapare alfa Capitolul este despre procesarea imaginilor prin acces direct la pixeli În plus, capitolul acoperă decodificarea și tipărirea imaginilor JPEG Exemple de programe Acest capitol discută două exemple de programe (Tabelul ) Important este că aceste două programe se bazează pe mai multe clase utile care vor fi folosite într-o formă îmbunătățită în alte capitole despre bitmaps Tabelul Programe capitolul Descriere director de proiect Samples\Chapt \Bitmaps Demonstrație de încărcare și salvare a fișierelor BMP, salvarea ecranului, diverse moduri de afișare a bitmap-urilor, aplicarea etichetelor bitmap-urilor și comenzilor de meniu, fundal bitmap, secțiuni DIB, ieșire independentă de dispozitiv folosind secțiuni DIB și ieșire bitmap în format hexazecimal Samples\Chapt \Scrambler Utilizarea funcției StretchBlt pentru a rearanja în mod aleatoriu plăcile ecranului Capitolul Utilizări non-triviale ale rasterelor Rasterele joacă un rol atât de important în programarea Windows, încât acest subiect nu poate fi tratat într-un singur capitol Capitolul anterior a descris cele trei tipuri de rastere acceptate de GDI: rastere independente de dispozitiv (DIB), rastere dependente de dispozitiv (DDB) și secțiuni DIB Am acoperit elementele de bază ale lucrului cu hărți de biți, inclusiv diferite moduri de a le afișa, folosind hărți de bit în interfața cu utilizatorul și chiar și programarea rezultatelor de înaltă rezoluție Totuși, capitolul anterior este departe de a epuiza subiectele bitmap-urilor În acest capitol, vom studia operațiunile bitmap, transparența și suprapunerea alfa Capitolul se ocupă de lucrul cu hărți de bit la nivel direct de pixeli, iar paletele sunt acoperite în Capitolul Operații ternare bitmap La desenarea liniilor sau la umplerea regiunilor, GDI folosește operații binare raster, care determină modul în care un pixel de creion sau pensulă este combinat cu un pixel de destinație și se obține un nou pixel de destinație Șaisprezece operațiuni binare raster sunt acceptate în GDI; o pereche de funcții SetR P și GetROP sunt folosite pentru a lucra cu ele Este destul de logic să presupunem că atunci când lucrați cu rastere, există operații raster similare care vă permit să creați tot felul de efecte speciale În acest caz, apare un nou factor - pixelii imaginii sursă Astfel, atunci când lucrați cu rastere, trebuie luați în considerare trei factori: culoarea pixelului stiloului sau al pensulei, culoarea pixelului de destinație și culoarea pixelului sursă Operații ternare bitmap ka Operațiile bitmap care combină aceste trei culori sunt denumite în mod obișnuit operațiuni bitmap ternare GDI acceptă numai operații logice pe biți, care sunt efectuate pe fiecare bit al unui pixel independent de alți pixeli și sunt limitate la operațiuni booleene AND (&), SAU (|), NOT (~) și XOR (A) În conformitate cu aceste restricții, există ( A( A ) sau ) posibile operații bitmap ternare Coduri de operare raster Un octet este suficient pentru a reprezenta de operații bitmap diferite Având în vedere că fiecare bit este interpretat independent de ceilalți, mecanismul de codificare pare a fi destul de simplu Să presupunem că P este un bit pentru stilou sau pensulă, S este un bit sursă și D este un bit destinație Dacă rezultatul unei operații raster este întotdeauna P, codul operației este OxFO Dacă rezultatul operației se potrivește întotdeauna cu S, codul este OxCC, iar dacă se potrivește întotdeauna cu D, atunci codul este OxAA Mai jos sunt definițiile acestor coduri de operare raster în C/C++: const BYTE hor R = OxFO; // const BYTE rop S = OxSS; // const BYTE rop D = OxAA; // Toate celelalte operațiuni raster sunt definite pe baza acestor trei constante prin operații booleene De exemplu, dacă, ca urmare a unei operații raster, S și P sunt combinate printr-o operație logică AND, este suficient să se calculeze rop S&rop P - se obține OxCO Dacă doriți o operație bitmap care returnează P dacă S = și D în caz contrar, calculați (rop S&rop P) | (~rop S&rop D); se dovedește -xE Pentru fiecare operație raster, există cel puțin o formulă de algebră booleană corespunzătoare care descrie exact operația raster în termeni de P, S și D Mai multe formule pot corespunde unei operații, dar toate sunt echivalente din punct de vedere logic Prin tradiție, aceste formule folosesc notația postfixă, în care operatorul se află în dreapta operanzilor Notația Postfix este convenabilă deoarece nu are nevoie de paranteze, iar logica sa este ușor de implementat în programele de calculator Dezvoltatorul raster a fost probabil un fan al Forth (un limbaj extensibil bazat pe stivă, fără verificarea tipului), PostScript sau calculatoarelor de inginerie HP care folosesc notația postfixă În notația raster postfixă, P, S și D sunt operanzi, iar a, o, n și x sunt operatori pentru AND, OR, NOT și, respectiv, XOR De exemplu, operația raster xE este scrisă ca DSPDxax Convertindu-l în notație infixă, obținem (S&(P*D))) Într-o formă mai vizuală, această formulă ar arăta astfel: (S&P)|(-S&D) sau SPaSnDao De ce se preferă prima formulă față de a doua? Din două motive Majoritatea procesoarelor implementează instrucțiunea XOR, care este la fel de rapidă ca și operația AND Prima formulă utilizează trei operații, în timp ce a doua utilizează patru Pentru a calcula prima formulă, doar una suplimentară Capitolul registru, iar pentru al doilea - două registre Mai jos este o implementare pseudocod a acestor formule (pentru un framebuffer codificat cu culori pe de biți): // Implementarea OxE DSPDxax conform schemei DA(S&(PAD)) mută eax, P // P xor eax, D // PAD și eax, S // S&(PAD) xor eax, D // DA(S&(PAD)) mov D, eax // Scrie rezultatul // Implementarea хЕ SPaSnDao conform schemei (S&P)|(-S&D) mută eax, S // S și eax P // S&P mov ebx, S // S nu ebx // ~S și ebx, D // -S&D sau eax, ebx // (S&P) | (-S&D) mov D, eax // Scrie rezultatul Operațiile bitmap în GDI sunt de obicei codificate cu DWORD pe de biți în loc de octeți simpli de la la Cuvântul înalt stochează unul dintre codurile operaționale bitmap de de biți pe un singur octet discutate mai sus; cuvântul scăzut conține codificarea formulei care definește operația bitmap Arhitectura originală folosește doar cuvântul scăzut pentru a defini operația bitmap; cuvântul înalt conține informații suplimentare pentru blitterele hardware În implementările mai vechi, operațiunile bitmap au fost codificate manual într-un asamblator optimizat, astfel încât algoritmii generali au fost preferați în loc de de cazuri diferite pentru diferite operații bitmap și un tabel mare de salt Implementările moderne folosesc un generator automat de operațiuni raster, care, spre deosebire de predecesorii săi, nu se plânge de necesitatea de a crea de funcții diferite Mecanismul de codificare a cuvintelor reduse al operațiunii bitmap ternar este o adevărată operă de artă, datând din vremurile în care programatorii trebuiau să se gândească cu atenție la fiecare linie de cod de mașină și să salveze fiecare bit de memorie Formulele de operații raster folosesc caractere diferite, iar lungimea formulei poate fi de până la caractere Cel mai simplu mecanism de codare ar avea nevoie de log ( ) sau , biți de informații pentru a face acest lucru, dar dezvoltatorii au trebuit să se limiteze la un cuvânt de biți Formula operației raster este împărțită în două părți: operatori și operanzi (similar cu stivele de operatori și operanzi de pe unele mașini de stivă) Operatorii sunt codificați cu cei mai semnificativi biți, iar restul de biți sunt lăsați pentru operanzi Din AND, bitul este folosit pentru a codifica cinci operații logice, doi biți per operație: - NOT, - XOR, - OR, - AND Ultimul bit de flag indică ultima operațiune NOT Este foarte dificil să codificați un șir de operanzi cu doar biți, dar programatorii inteligenți au găsit lanțuri repetate în șiruri de operanzi În total, au fost alocate astfel de lanțuri, pentru codificarea cărora sunt suficienți trei biți Ultimii doi biți determină cantitatea de deplasare a șirului Schema de codificare pentru cuvântul inferior al operațiilor ternare GDI este prezentată în fig Operații ternare bitmap Orez Structura de cuvinte scăzută a unei operațiuni bitmap Desigur, ceea ce s-a spus ar trebui clarificat cu un exemplu concret Luați operația raster xE ; codul operațional raster complet este x E , deci cuvântul scăzut este x Astfel, Op = NU, Op = NU, Op = XOR, Op = ȘI, Opl = XOR, nu este necesar NU suplimentar, indicele de treaptă și decalajul Treapta SPDSPDSP este deplasată cu două caractere pentru a da DSPDSPSP Avem cinci operatori, dar doar trei dintre ei sunt binari; ultimele două sunt unare Prin urmare, doar patru operanzi sunt utilizați efectiv Lanțul este trunchiat la DSPD; aplicarea operatorilor incepand de la ultimul caracter ne da DSPDxaxnn, sau dupa simplificare - DSPDxax; această linie definește operația bitmap în GDI Semnele „+” și „-” din șiruri se numesc operanzi speciali Dintre cele de operații raster, nu pot fi exprimate folosind un acumulator simplu care stochează o singură valoare calculată Pentru aceste operațiuni bitmap, rezultatul intermediar este împins în stivă și apoi este afișat după cum este necesar Operanzii speciali sunt întotdeauna înlănțuiți în perechi Prima dată, rezultatul curent este împins pe stivă, iar următorul operand este încărcat; a doua oară, rezultatul curent este combinat cu valoarea stocată pe stivă printr-o operație logică binară Intern, acești operanzi speciali sunt reprezentați de aceiași biți ( x ), astfel încât șirul să se potrivească într-un cuvânt de biți Pe fig , semnul „-” corespunde cu împingerea pe stivă, iar semnul „+” cu scoaterea din stivă Nu uitați că lanțurile sunt citite în ordine inversă Desigur, această structură arhaică glorioasă salvează memoria și codul de asamblare, dar acest lucru se realizează în detrimentul vitezei și vizibilității Implementările mai noi ale GDI nu mai folosesc acest mecanism lent, astfel încât cuvântul de ordin scăzut al unei operații ternare poate fi, în general, ignorat în siguranță Cu toate acestea, este dificil de spus cu certitudine dacă un anumit driver de dispozitiv grafic ar dori să verifice o potrivire exactă a tuturor biților unui cod pe de biți Capitolul operare raster, deci pentru fiabilitate este recomandat să verificați codul complet de operare raster și să îl utilizați Operațiunile ternare bitmap folosesc doar de biți din codul ROP de de biți Cei biți superiori ai codului sunt de obicei umpluți cu zerouri Windows și Windows au introdus două indicatoare noi care controlează copierea bitmap: CAPTUREBLT și NOMIRRORBITMAP Steagul CAPTUREBLT ( x ) este utilizat atunci când aveți de-a face cu ferestre care au propria suprafață de afișare care poate fi îmbinată cu conținutul altor ferestre prin amestecare alfa Când utilizați steag-ul CAPTUREBLT, pixelii tuturor ferestrelor situate deasupra ferestrei curente sunt incluși în imaginea finală În mod implicit, imaginea constă numai din conținutul ferestrei curente Indicatorul NOMIRRORBITMAP ( x ) previne oglindirea rasterelor pe verticală și orizontală din cauza diferitelor axe din dreptunghiurile sursă și destinație Diagrama operațiilor raster ternare Formulele algebrice pentru operațiile raster sunt precise și convenabile, dar o reprezentare vizuală vă va ajuta să înțelegeți mai bine numeroasele varietăți ale acestor operații După ce am creat șabloane pentru trei variabile, vom putea genera rasterul final folosind formule algebrice și vom putea vedea vizual rezultatele aplicării tuturor operațiilor Pe fig Figura prezintă o diagramă simplă a operațiilor raster ternare, obținute prin aplicarea operațiilor raster la cele trei rastere prezentate în stânga Orez Diagrama operațiilor raster ternare Operații ternare bitmap Modelul raster ( x pixeli) a fost generat folosind modelul OxFO în direcțiile X și Y Sursa a fost generată folosind modelul OxCC, iar destinația a fost generată folosind modelul OxAA În acest exemplu, albul este un boolean și negru este un zero boolean de rastere mici reprezintă toate rezultatele posibile ale operațiunilor raster Acestea sunt generate prin crearea unei pensule de model dintr-un bitmap de model și apoi îmbinând sursa cu destinația cu pensula de model selectată Mai jos este codul folosit pentru a reprezenta diagrama operațiunilor raster Rețineți că sunt necesare hărți de biți x pentru ca pensula de model să funcționeze și pe sistemele din familia Windows Rasterul este generat într-un context de dispozitiv compatibil și apoi scalat la contextul dispozitivului de pe ecran, deoarece periile de model nu se scalează const WORD B t Pattern[] = { OxFO, OxFO, OxFO OxFO, OxOF, OxOF OxOF, OxOF}; const WORD B t Source □ = { OxCC OxCC x , x OxCC OxCC x x }: const WORD B t Destinat on[] = { OxAA x , OxAA, x , OxAA, x , OxAA, x }; void Rop Chart (HDC hDC) { HBITMAP Pbmp = CreateB tmap( , , B t Pattern); HBITMAP Sbmp = CreateB tmap( , B t Source); HBITMAP Dbmp = CreateB tmap( , , B t Dest nat on): HBITMAP Rbmp = CreateB tmap( , , , NULL); HBRUSH Pat = CreatePatternBrush(Pbmp); // pensula model HDC Sr = CreateCompatlbleDC(hDC); // Îmbinare DC pentru sursă HDC Dst = CreateCompatibleDC(hDC): // Compatibil DC pentru receptor HDC Rst = CreateCompatlbleDC(hDC): // Compat DC pentru rezultat SelectObject(Src sbmp); SelectObject(Dst, Dbmp); SelectObjectCRst, Pbmp); StretchBlt(hDC, , , Rst, , SRCCOPY); StretchBltChDC, , , , Src SRCCOPY); StretchBltChDC , , , , Dst, , SRCCOPY); SetBkMode(hDC, TRANSPARENT); TextOut(hDC, , , „Model”, ); TextOutChDC , , „Sursa”, ); TextOutChDC „Destinatlon” unsprezece); SelectObjectCRst, Rbmp); SelectațiObjectCRst Pat); pentru (Int = ; bmiHeader biWidth; int inaltime = pBMI->bmiHeader biHeight; bmi bpp bmi bpp; memset(&bmi bpp sizeof(bmi bpp)): bmi bpp bmi Header biSize bmi bpp bmi Antet bi Latime bmi bpp bmi Header bi Hei ght bmi bpp bmi Header bi Pianes bmi bpp bmi Header bi Bi tCount bmi bpp bmi Header bi Compressi » sizeof(BITMAPINFOHEADER); s-lățime; -înălţime: - unu; - opt; - BI RGB; pentru (int - ; i =nXSrc) && (sx =nYSrc) && (sy maxx) maxx = x ; dacă ( x maxx) maxx = x : } clasa KReverseAffine : public Kaffine { int xO, yO xl, yl, x , y ; public: int minx, maxx, miny, maxy; KReverseAffine(const POINT * pPoint) { xO = pPoint[ ] x: // PO PI yO » pPoint[ ] y; // xl = pPunc[l] x; // yl="pPointEl] y: // P P x = pPoint[ ] x; y « pPoint[ ] y: bool Simplu(void) const { return (yO-yl) && (x ==x ): } void Setupdnt nXSrc int nYSrc int nWidth int nHeight) { MapTri(xO, yO xl, yl x , y nXSrc, nYSrc, nXSrc+nWidth, nYSrc nXSrc, nYSrc+nHeight); minmax(xO xl x , x + xl - xO minx, maxx); minmaxCyO, yl y y + yl - yO mini maxy): } Tocmai am implementat primul nostru algoritm de rotație/deplasare și am creat un înlocuitor pentru funcția puternică PlgBlt Dacă rulați acest program, acesta va construi aproape același cub volumetric ca în Fig Adevărat, funcționează de aproximativ ori mai lent, deoarece folosește funcțiile lente GetPixel/SetPixel Mai târziu în acest capitol, vom descrie tehnici de acces direct la pixeli care măresc semnificativ viteza programului Rastere transparente Operații cuaternare bitmap: MaskBIt Probabil, unii superiori de la Microsoft au considerat că operațiunile bitmap ternare nu sunt suficient de complexe, așa că ar trebui adăugate operațiunilor bitmap cuaternare care depind de patru variabile Acest lucru pare destul de ciudat, având în vedere că în GDI o singură operație bitmap ternară, în funcție de model, sursă și destinație, a primit un nume - PATPAINT (PI ~S ID) Nici nu știm cum să folosim PATPAINT, deși secțiunea anterioară a arătat câteva operații ternare care depind de toate cele trei variabile Un cod de operare raster ternar poate fi văzut ca o combinație a două coduri de operare raster binare Jumătatea superioară a codului de operare bitmap ternar este utilizată când P = ; jumătatea inferioară este utilizată când P = Ca exemplu, luați în considerare operația raster de înlocuire identică cu codul xAA; atât jumătatea mai în vârstă, cât și jumătatea mai tânără sunt egale cu OxA Prin urmare, rezultatul unei operații bitmap nu depinde deloc de perie Codul D este xA, deci rezultatul este întotdeauna D, adică starea inițială a receptorului Acum luați în considerare operația PATINVERT cu codul x A Jumătatea superioară este x , iar jumătatea inferioară este xA Prin urmare, când P este , se utilizează operația bitmap -D, iar când P = , se utilizează operația D, rezultând PXD Al patrulea factor în operațiile cu raster cuaternar este rasterul masca monocromă Codul de operare raster cuaternar constă din două coduri de operare ternare: principal și de fundal Operația principală este utilizată când pixelul măștii este , iar operația de fundal este utilizată pentru pixelii măști egali cu GDI definește macro-ul MAKER P , care combină două coduri ternare de de biți într-un cod cuaternar de de biți #define MAKER P (înainte spate) (DWORD) ((((în spate)" ) & OxFFOOOOOO) | (înainte) Macro-ul preia un opcode bitmap de biți, îl deplasează cu biți la stânga și îl concatenează cu opcode-ul principal de de biți Rezultatul este un opcode cuaternar pe de biți Structura codului ROP cuaternar este prezentată în fig Opcode complet pe de biți ^Codificarea formulei operației principale biți ->| Index de funcționare de fundal Index de funcționare principal Or Or Or Or Or Cod de operare cuaternar complet pe de biți Nu Orez Cod de operare raster cuaternar Analizează șirul decalaj Masca în operațiile cuaternare nu este un factor egal, deoarece este limitată la doar două valori: (alb) și (negru) Nu puteți crea o mască de culoare ai cărei pixeli de culoare sunt îmbinați cu pixelii de culoare ai pensulei, sursei și destinației Cuaternar Capitolul I Utilizări non-triviale ale rasterelor operațiunile au fost concepute în primul rând ca un mijloc simplu și eficient de redare transparentă a bitmap-ului, iar MaskBlt este singura funcție GDI care utilizează un cod de operare bitmap cuaternar Înțelegerea modului în care funcționează funcția MaskBlt nu este atât de dificilă Primii cinci parametri definesc un dreptunghi pe suprafața de recepție Următorii trei parametri definesc un dreptunghi pe suprafața sursei, ale cărui dimensiuni sunt aceleași cu dimensiunile suprafeței de recepție Aceștia sunt aceiași opt parametri care sunt utilizați în BitBlt Cu toate acestea, funcția de pereche StretchMaskBlt (prin analogie cu perechea BitBlt/StretchBlt) nu există Dacă o aplicație dorește să scaleze atunci când apelează MaskBlt, trebuie să seteze sistemele de coordonate logice în mod corespunzător Următorii trei parametri, hbmMask, xMask și yMask, definesc rasterul măștii Masca este duplicată după principiul mozaicului, prin analogie cu masca PlgBlt Ultimul parametru MaskBlt specifică o operație de bitmap cuaternar Dacă pixelul măștii este , noul pixel de suprafață de destinație este determinat de pixelii pensulă, sursă și destinație combinați de operația raster principală; în caz contrar, se folosește o operație raster de fundal Găsirea unui exemplu bun care să demonstreze utilizarea MaskBlt nu este ușoară, așa că vom folosi din nou exemplul de redare a pictogramei: void MaskBltDrawIcon(HDC hDC int x, int y, HICON hlcon) { ICONINFO info icon: GetlconlinfoChlcon, &iconinfo): BITMAP bmp: GetObject(iconinfo hbmMask, sizeof(bmp) și bmp): HDC hMemDC = CreateCompatibleDC(NULL): HGDIOBJ hold = SelectObject(hMemDC, iconinfo hbmColor): MaskBlt(hDC, x y, bmp bmWidth, bmp bmHeight, hMemDC, , , iconinfo hbmMask, MAKER P (SRCINVERT SRCCOPY)): SelectObject(hMemDC, hold): DeleteObject(iconinfo hbmMask): DeleteObject(iconinfo hbmColor): DeleteObject(hMemDC): } Spre deosebire de programul anterior, ne-am descurcat cu un singur apel de funcție În comparație cu funcția MaskBltmapNT, care folosește o perie de model și operația de bitmap exotică x C E (SX(PXD)), trecem masca direct când apelăm MaskBlt fără a aplica pensula de model Acest exemplu utilizează operația raster cuaternar MAKER P (SRCINVERT, SRCCOPY), care efectuează o operație XOR logică pentru pixelii masca de și o copie simplă pentru pixeli masca zero Aceste operațiuni respectă regulile de afișare a pictogramelor În practică, pixelii cu un singur nucleu corespund cu zero pixeli ai rasterului de culoare, astfel încât operația XOR nu schimbă pixelul destinație Rastere transparente Imitația MaskBIt Funcția MaskBIt oferă un model conceptual simplu pentru efectuarea diferitelor operații raster pe pixelii din prim-plan și din fundal Din păcate, aplicațiile care folosesc MaskBIt funcționează doar pe sistemele de operare din familia Windows NT În această secțiune, vom dezvolta un model al funcției MaskBIt pentru alte sisteme Modelarea MaskBIt este un exercițiu foarte bun pentru a înțelege mai bine utilizarea operațiilor raster Vom fi imediat de acord că nu vom implementa operațiuni raster la nivel de pixel, deoarece pentru aceasta va trebui să programăm toate cele de operațiuni raster ternare de care depinde funcția MaskBIt În schimb, vom încerca să imitem MaskBIt cu câteva operații ternare Desigur, acest lucru va duce la o oarecare scădere a performanței, dar pierderile sunt justificate de valoarea cognitivă a unui astfel de exercițiu Funcția G MaskBlt (Listarea ) implementează pe deplin toate caracteristicile BitBlt Sarcina este împărțită în mai multe subsarcini - de la cele simple, care nu utilizează mai mult de trei operațiuni raster, la altele mai generale, care necesită un raster temporar și șase operațiuni raster Funcția extrage mai întâi indicii operației principale și de fundal din codul ROP cuaternar După cum sa menționat mai sus, funcția MaskBIt trebuie să utilizeze operația raster principală pentru pixeli unici ai măștii (alb) și operația de fundal pentru zero pixeli (negru) Prin urmare, implementarea noastră trebuie să fie orientată către execuția a două POR: principal și background Lista Imitația MaskBIt BOOL TriBitBlt(HDC hdcDest int nXDest int nYDest, int nWidth int nHeight, HDC hdcSrc int nXSrc int nYSrc HBITMAP hbmMask intxmask int yMask, DWORD ropl DWORD rop , DWORD rop ) { HDC hMemDC = CreateCompatibleDC(hdcDest); SelectObject(hMemDC, hbmMask); dacă ( (ropl" ) != xAA ) // nu D BitBltChdcDest, nXDest nYDest, nWidth nÎnălțime, hdcSrc, nXSrc nYSrc, ropl); BitBlt(hdcDest, nXDest, nYDest nWidth, nHeight, hMemDC, xMask, yMask, rop ); DeleteObject(hMemDC): dacă ((rop " )!= xAA ) // nu D returnează BitBlt(hdcDest nXDest, nYDest, nWidth, nHeight, hdcSrc, nXSrc, nYSrc rop ): altfel returnează TRUE; } ini ine bool D independent(DWORD rop) Capitolul { return ((OxAA & rop)"l)== ( x & rop); } inline bool S independent(DWORD rop) { return ((OxCC & rop)" )== ( x & rop): } BOOL G MaskBlt(HDC hdcDest, int nXDest, int nYDest, Int nWidth, int nHeight, HDC hdcSrc int nXSrc int nYSrc HBITMAP hbmMask intxmask masca int, DWORD dwRop ) { DWORD înapoi = (dwRop » ) & OxFF: DWORD fore = (dwRop » ) & OxFF; if ( back==fore ) // operația principală este aceeași cu cea de fundal // Masca hbmMask nu este necesară returnează BitBlt(hdcDest nXDest, nYDest, nWidth nHeight, hdcSrc, nXSrc, nYSrc, dwRop & OxFFFFFF): // dacă (M) D=înainte(PSD) altfel D=înapoi(PSD) if ( D independent(back) ) // Operația de fundal nu depinde de D return TriBitBlt(hdcDest, nXDest, nYDest, nWidth, nHeight, hdcSrc, nXSrc, nYSrc, hbmMask xMask, yMask, foreAback " /,/ (foreAback) inapoi) SRCAND, // ( în față înapoi, ) (backA xAA) " ): // { înainte, spate } if ( D independent(fore) ) // Operația principală este independentă de D return TriBitBlt(hdcDest nXDest, nYDest nWidth, nHeight, hdcSrc, nXSrc, nYSrc, hbmMask xMask, yMask, (foreAback) // (foreAback) " A , înainte în spate ) x " // ( foreAback) (foreA xAA) " ): // { înainte înapoi} // Atât operația principală, cât și cea de fundal depind de D dacă ( S independent(back) && SJndependent(fore) ) return TriBitBlt(hdcDest, nXDest nYDest, nWidth, nHeight, NULL, , , hbmMask, xMask, yMask, OxAA « // ( D D ) ( (în față și OxCC) || (în spate și x ) ) " OxAA « ); // Atât operația principală, cât și cea de fundal depind de D // Operația principală sau de fundal depinde de S HBITMAP hTemp = CreateCompatibleBitmap(hdcDest, nWidth, nHeight): HDC hMemDC = CreateCompatibleDC(hdcDest): SelectObject(hMemDC, hTemp): BitBlt(hMemDC, , , nWidth, nHeight hdcDest, nXDest nYDest SRCCOPY): SelectObject(hMemDC GetCurrentObject(hdcDest OBJ BRUSH)): Continuare^ Rastere transparente Lista Continuare BitBlt(hMemDC , nWidth nHeight, hdcSrc nXSrc nYSrc înapoi " ): // hMemDC conține // imaginea de fundal rezultată BltBlt(hdcDest , , nWidth nHeight, hdcSrc, nXSrc, nYSrc înainte " ): // Imaginea principală Tr BltBlt(hdcDest, nXDest, nYDest, nWidth, nHeight, hMemDC, , , hbmMask, xMask, yMask SRCINVERT // ( forexback forexback ) SRCAND, // ( forexback, ) SRCINVERT): // { înainte înapoi} DeleteObject(hMemDC): DeleteObject(hTemp); returnează TRUE: } Dacă operația de bitmap principală este aceeași cu cea de fundal, masca de bitmap nu este utilizată, iar sarcina este rezolvată cu un singur apel la W tBl t Dacă operația de bitmap de fundal este independentă de bitmap-ul de destinație, MaskBlt este implementat prin cel mult trei apeluri către BitBlt Primul apel folosește bitmap-ul sursă și operația de bază XOR bitmap de fundal Al doilea apel folosește masca și operațiunea bitmap SRCAND, determinând receptorul să intre în starea „dacă (M) (baseAfon) altfel ” Al treilea apel folosește bitmap-ul sursă și operația de fundal XOR D Ca rezultat, suprafața de recepție intră în starea „dacă (M) bază alt fundal” - asta este exact ceea ce ne-am dorit Luați în considerare un exemplu Să presupunem că operația de bitmap principală are formula DXS, iar operația de fundal are formula P Prin urmare, rezultatul pe care vrem să-l obținem este „dacă (M) DXS altfel P” Conform algoritmului de mai sus, prima operație bitmap este descrisă de formula DXS^P După aplicarea măștii cu operația SRCAND, trecem la formula „dacă (M) D^S^P altfel ” În cele din urmă, harta de biți sursă este reutilizată cu o operație D^P, iar rezultatul este „dacă (M) D^S altfel P” De ce solicităm ca operațiunea raster în fundal să fie independentă de destinație? Deoarece prima operație bitmap schimbă starea receptorului Pentru toate operațiunile raster ulterioare care utilizează starea originală a țintei, trebuie să creați o copie a acesteia În mod similar, dacă operația raster principală este independentă de țintă, este suficient să folosiți operația NOTSRCAND ( x ) ca a doua operație și (bază A ) ca a treia operație Un alt caz simplu este atunci când atât operațiile principale, cât și cele de fundal sunt independente de sursă În acest caz, putem interpreta masca ca sursă, putem construi o nouă operație bitmap și putem efectua BitBlt atunci când masca este selectată într-un context de dispozitiv compatibil Indicele ROP este calculat ca (bază& xCC)|(fondul& x ), unde xCC este sursa și x este „NU sursă” După cum puteți vedea, putem dezasambla ROP-ul în componentele sale și le putem reasambla Să presupunem că operația principală este ROP PATCOPY (OxFO) și operația de fundal este PATINVERT ( x A); ambele operatii nu depind de S Noul Capitolul I Utilizări non-triviale ale rasterelor Operația triplă este calculată prin formula ( xF & xCC)|( x A& x ), adică xC | x = xD sau PX(D&~S) Vă rugăm să rețineți că rolul lui S în acest caz este rasterul de mască Această formulă înseamnă că pentru S = , ar trebui utilizată operația P, iar pentru S = , P^D Dacă nici operația principală, nici cea de fundal nu este unul dintre aceste cazuri simple, apar probleme Știm că ambele operațiuni raster (prim-plan și fundal) depind de țintă, dar nu putem obține efectul dorit cu un singur apel către BitBlt După primul apel către BitBl t, receptorul se schimbă, astfel încât toate referințele ulterioare la acesta se vor referi la starea schimbată a receptorului și nu la starea originală a receptorului Există o singură cale de ieșire - pentru a crea un raster temporar, copiați suprafața de primire în ea și apoi creați o imagine de fundal pe ea După aceea, imaginea principală este construită pe suprafața principală de recepție, care este combinată cu imaginea de fundal folosind o mască Astfel, funcția MaskBIt este modelată prin mai multe apeluri către BitBlt - de la unu la șase Taste de culoare: TransparentBIt Ambele funcții, PlgBlt și MaskBIt, folosesc o mască de bitmap monocromă pentru a controla ieșirea bitmap-ului sursă Principalul dezavantaj al soluțiilor bazate pe mască este că trebuie să creăm două rastere perfect potrivite: sursa și masca Masca trebuie să se potrivească exact cu sursa atât ca dimensiune, cât și în cele mai mici detalii ale imaginii Construirea acestor rastere necesită multă muncă monotonă Soluția la această problemă ar trebui căutată la Hollywood, cu specialiști în efecte vizuale Cinematograful a folosit de mult tehnica filmării combinate cu utilizarea așa-numitului „ecran albastru” În primul rând, fotografia este făcută pe un ecran albastru iluminat uniform În timpul procesului de editare, fundalul albastru este înlocuit cu o altă imagine „de fundal” De exemplu, un actor poate fi filmat într-un studio suspendat de câteva corzi neobservate, apoi suprapus pe imaginea cerului; Se pare că o persoană plutește în aer Apropo, albastrul nu este singura culoare posibilă, deși este folosită cel mai des în timpul filmărilor Există o altă tehnică care funcționează pe același principiu - toate zonele imaginii a căror luminozitate depășește un anumit prag (sau invers, se dovedește a fi sub acesta) sunt înlocuite cu secțiuni ale unei alte imagini Aceste două tehnici se bazează pe utilizarea așa-numitelor taste de culoare În GDI pe platformele Windows și Windows , a fost introdus suportul pentru cheile de culoare cu noua caracteristică TransparentBIt Când este apelată, funcția TransparentBIt primește parametri AND Primii cinci parametri definesc dreptunghiul suprafeței de recepție a dispozitivului, următorii cinci sunt dreptunghiul de pe suprafața sursei, iar ultimul parametru este cheia de culoare specificată ca valoare RGB Funcția TransparentBIt copiază pixelii sursă care nu se potrivesc cu cheia de culoare pe suprafața de recepție; imaginea este mărită sau redusă după cum este necesar fiţi atenți Rastere transparente Notă: Funcția TransparentBIt, spre deosebire de StretchBlt, nu acceptă oglindire Dacă rasterul a fost preprocesat pentru a aplica o cheie de culoare, utilizarea funcției TransparentBIt este foarte ușoară Să revenim la afișarea pictogramelor, dar de data aceasta folosind funcția TransparentBIt Rețineți: o pictogramă constă dintr-o mască monocromă și un bitmap color Zonele transparente ale ecranului color sunt de obicei vopsite în negru Dacă negru nu apare într-o imagine, de obicei este ales pentru a indica transparența Ca regulă generală, cheia de culoare este de obicei determinată de culoarea primului pixel al rasterului Următoarea funcție determină culoarea primului pixel al rasterului pictogramei și o trece ca cheie de culoare atunci când apelați TransparentBIt Astfel, pictograma este afișată cu o singură funcție de blitting void TransparentBltDrawIcon(HDC hDC int x, int y HICON hlcon) { ICONINFO info icon: GetlconInfo(hlcon și iconinfo): BITMAP bmp: GetObject(iconinfo hbmMask sizeof(bmp) și bmp): HDC hMemDC = CreateCompatibleDC(NULL); HGDIOBJ hold = SelectObject(hMemDC iconinfo hbmColor); COLORREF crTrans = GetPixel(hMemDC ): TransparentBlt(hDC xy bmp bmWidth bmp bmHeight hMemDC bmp bmWidth bmp bmHeight, crTrans): SelectObject(hMemDC Hold): DeleteObject(iconinfo hbmMask): DeleteObject(i eoninfo hbmColor): DeleteObject(hMemDC): } Caracteristica TransparentBIt este destul de impresionantă, mai ales având în vedere originile sale „Hollywood” Din păcate, este acceptat numai pe Windows , Windows și sisteme ulterioare Windows NT nu acceptă TransparentBIt Această funcție nu este exportată din GDI DLL, ci din MSIM DLL, așa că o bibliotecă suplimentară MSIMG DLL trebuie inclusă în programul dumneavoastră Implementarea TransparentBIt de către Windows duce la scurgeri de resurse, așa că nu este recomandat să folosiți această funcție pe scară largă Pe scurt, avem suficiente motive pentru a ne crea propria noastră implementare independentă de platformă Imitație TransparentBIt Unul dintre cei mai importanți pași în implementarea TransparenBlt este construirea unui raster de mască dintr-o cheie de culoare Rasterele DDB monocrome au mijloace foarte convenabile pentru crearea măștilor Amintiți-vă că atunci când o imagine color este convertită într-un raster monocrom, toți pixelii care se potrivesc cu culoarea de fundal a contextului de recepție sunt convertiți la (alb), iar restul Capitolul I Utilizări non-triviale ale rasterelor pixelilor li se atribuie (negru) De asemenea, rețineți că o culoare de fundal albă este atribuită contextului implicit al dispozitivului Rasterul de mască necesită, de asemenea, un context de dispozitiv compatibil În unele aplicații, cheltuiala creării unei măști și a unui context de dispozitiv compatibil pentru fiecare ieșire raster poate fi inacceptabilă Lista - arată o implementare Transparenteit care utilizează clasa de ajutor KDDBMask pentru a gestiona rasterul măștii și contextul dispozitivului compatibil Funcția G TransparentBlt creează o instanță a clasei KDDBMask pe stivă, creează o mască și apoi o folosește pentru a desena transparent bitmap-ul original În aplicațiile dvs , puteți elimina instanța de mască la un nivel superior pentru a evita crearea acesteia de mai multe ori Lista Imitație TransparentBIt BOOL G TransparentBlt(HDC hdcDest int nDxo, int nDyO int nDw, int nDh, HDC hdcSrc int nSxO, int nSyO int nSw int nSh UINT crTransparent) Masca KDDBMasca: mask Create(hdcSrc nSxO, nSyO nSw nSh crTransparent): masca de returnare TransBlt(hdcDest, nDxO nDyO, nDw nDh hdcSrc nSxO, nSyO, nSw, nSh); } clasa KDDBMask { HDC m hMemDC: HBITMAP m hMask; HBITMAP m hOld; int mjiMaskWidth; int m nMaskHeight: void Eliberare (void) { dacă (mJiMemDC) { SelectObject(m hMemDC m hOld): DeleteObject(m hMemDC): m hMemDC = NULL: m hOld = NULL: dacă ( m hMask ) ( DeleteObject(m hMask); mJiMask = NULL; } } public: KDDBMask() Rastere transparente mJiMemDC=NULL: mJiMask - NULL: mJiOld = NULL: } -KDDBMaskO { ReleaseO: } BOOL CreateCHDC hDC, int nX int nY int nWidth, int nHeight, UINT crTransparent): BOOL ApplyMask(HDC HDC, int nX, int nY, int nWidth, int nHeight DWORD Rop): BOOL TransBltCHDC hdcDest, int nDxO, int nDyO, int nDw, int nDh, HDC hdcSrc int nSxO int nSyO int nSw intnSh); }: // Creați un raster de mască monocrom din DC sursă BOOL KDDBMask::Create(HDC hDC int nX int nY int nWidth int nHeight UINT crTransparent) { eliberare(): RECT rect = { nX, nY, nX + nWidth nY + nÎnălțime}: LPtoDP(hDC (PUNCTUL *) și rect ): m nMaskWidth = abs(rect right - rect left); mjiMaskHeight = abs(rect bottom - rect top): // Obțineți real // dimensiuni // Creați context compatibil și mască monocromă m hMemDC = CreateCompatibleDC(hDC): m hMask = CreateBitmap(m nMaskWidth mjiMaskHeight NULL): m h d = (HBITMAP) SelectObject(mJiMemDC, mJiMask); COLORREF oldBk = SetBkColor(hDC crTransparent): // Asociați // crTransparent cu // (culoare albă) BOOL rslt = StretchBlt(mJiMemDC , , mjiMaskWidth mjiMaskHeight, hDC, nX, nY, nWidth nHeight SRCCOPY): SetBkColor(hDC oldBk): return rslt: } BOOL KDDBMask::ApplyMask(HDC hDC int nX int nY int nWidth int nÎnălțime DWORD rop) { COLORREF oldFore = SetTextColor(hDC RGB( )): // Negru COLORREF oldBack = SetBkColor(hDC RGB( , )): // Alb BOOL rslt = StretchBlt(hDC nX nY nWidth nHeight mJiMemDC , mjiMaskWidth, mjiMaskHeight rop): Continuare Capitolul I Utilizări non-triviale ale rasterelor Lista Continuare SetTextColor(hDC, oldFore); SetBcCo sau(hDC, oldBack); return rslt; } // D=DXS D=D&Mască D=DXS > dacă (Mască==l) D else S BOOL KDDBMask::TransBlt(HDC hdcDest int nDxO, int nDyO int nDw int nDh HDC hdcSrc int nSxO, int nSyO, int nSw int nSh) { StretchBlt(hdcDest nDxO nDyO, nDw, nDh hdcSrc nSxO nSyO nSw nSh SRCINVERT): // DAS Aplicați MasklhdcDest nDxO nDyO, nDw, nDh, SRCAND): // dacă trans D'S altfel return StretchBltlhdcDest nDxO nDyO nDw, nDh, hdcSrc nSxO nSyO nSw nSh, SRCINVERT): // dacă trans D else S } Metoda KDDBMask::Create creează un raster monocrom având în vedere un context de dispozitiv bazat pe o cheie de culoare Metoda calculează dimensiunile rasterului prin maparea dreptunghiului sursă la sistemul de coordonate al dispozitivului (în cazul în care modul de afișare implicit MM TEXT nu este utilizat în contextul dispozitivului sursă) Conversia efectivă a unui bitmap color în monocrom depinde de culoarea de fundal a contextului original al dispozitivului Metoda KDDB: :TransBlt folosește secvența familiară SRCINVERT/SRCAND/SRCINVERT de operații bitmap pentru a obține un efect transparent Transparență fără mască În aproape toate metodele de ieșire raster transparentă, este utilizat un raster monocrom, care joacă rolul unei măști Resursele de cursor și pictograme au o mască încorporată; rasterul masca este trecut la funcțiile PlgBlt și MaskBIt ca parametri Singura excepție este funcția TransparentBIt, care funcționează cu taste de culoare Cu toate acestea, în simularea noastră, am revenit la lucrul cu măști Apare întrebarea: cum să implementăm transparența fără a folosi măști? De exemplu, dacă masca este din anumite motive dificil de creat sau consumă multe resurse? Există soluții alternative? Această secțiune discută unele dintre aceste alternative Ieșire transparentă folosind forme geometrice Algoritmul de inferență transparent bazat pe mască constă din trei pași Transparență fără mască Aplicarea unui model pe suprafața de recepție utilizând operația XOR Combinarea măștii cu suprafața de primire folosind operația AND Reaplicarea modelului pe suprafața de recepție prin operația XOR După aceste trei etape, zona corespunzătoare culorii negre ( ) a măștii este înlocuită cu imaginea sursă, iar pixelii rămași rămân neschimbați Rețineți că masca este folosită o singură dată pentru a umple zonele opace cu culoarea neagră ( ) Dacă zona formată de pixelii negri ai măștii poate fi descrisă ca un set de forme geometrice, atunci în loc să se creeze un raster separat, masca poate fi desenată folosind comenzile de umplere a zonei GDI Mai jos este un exemplu de desenare a unui raster DIB eliptic fără un raster de mască BOOL OvalStretchDIBits(HDC hDC int XDest int YDest int nDestWidth int nDestHeight int XSrc, int YSrc int nSrcWidth int nSrcHeight, const void *pBits, const BITMAPINFO *pBMI, UINT iUsage) { StretchDIBits(hDC XDest YDest nDestWidth nDestHeight XSrc YSrc nSrcWidth nSrcHeight pBits pBMI iUsage SRCINVERT); SaveDC(hDC); SelectObject(hDC GetStockObject(BLACK BRUSH)); SelectObject(hDC GetStockObject(BLACK PEN)); Elipse(hDC XDest YDest XDest + nDestWidth YDest + nDestHeight); RestoreDC(hDC - ); returnează StretchDIBits(hDC XDest YDest nDestWidth nDestHeight xsrc YSrc nSrcWidth nSrcHeight pBiți pBMI iUsage SRCINVERT); Această funcție desenează mai întâi sursa folosind funcția StretchDIBits cu operația de bitmap SRCINVERT, apoi desenează elipsa cu funcția El lipse Apelarea StretchDIBits din nou cu operația SRCINVERT asigură că imaginea va fi desenată numai în zonele care se află în interiorul elipsei Când utilizați funcția OvalStretchDIBits pentru a desena o hartă de biți non-trivială, apare o pâlpâire enervantă, deoarece inversarea pixelilor este un proces relativ lent Pentru a reduce pâlpâirea, puteți împrumuta structura bitmap de culoare din pictograme, unde pixelii transparenți sunt de obicei negri În acest caz, după pictarea în negru a zonei opace a destinației, puteți utiliza operația bitmap SRCPAINT pentru a îmbina sursa cu destinația Se presupune că putem modifica bitmap-ul sursă astfel încât pixelii săi transparenți să fie colorați în negru; acest lucru se poate face folosind secțiunea DDB sau DIB selectată într-un context de dispozitiv compatibil Funcția Oval StretchBl t ilustrează această idee BOOL OvalStretchBlt(HDC hDC int XDest int YDest int nDestWidth int nDestHeight HDC hDCSrc intXSrc int YSrc int nSrcWidth int nSrcHeight) { // Colorează sursa în afara elipsei NEGRU Capitolul I Utilizări non-triviale ale rasterelor SaveDC(hDCSrc); BeginPath(hDCSrc); Dreptunghi (hDCSrc, XSrc, YSrc, XSrc + nSrcWidth+ , YSrc + nSrcHeight+ ); EHipse(hDCSrc, XSrc, YSrc, XSrc + nSrcWidth, YSrc + nSrcHeight); EndPath(hDCSrc); SelectObject(hDCSrc GetStockObject(BLACK BRUSH)): SelectObject(hDCSrc, GetStockObject(BLACK PEN)); Fi Path(hDCSrc): RestoreDC(hDCSrc, - ): // Desenați o elipsă NEGRA pe suprafața de primire SalvareDC(hDC): SelectObject(hDC, GetStockObject(BLACKJ RUSH)): SelectObject(hDC, GetStockObject(BLACK PEN)); El pse(hDC XDest, YDest, XDest + nDestWidth, YDest + nDestHeight): RestoreDC(hDC, - ): // Combină sursa cu destinația returnează StretchBlt(hDC, XDest, YDest, nDestWidth, nDestHeight hDCSrc, XSrc, YSrc, nSrcWidth nSrcHeight, SRCPAINT); } În primul rând, folosim funcțiile de cale pentru a picta zona din afara elipsei cu o pensulă neagră Pixelii din interiorul elipsei rămân neschimbați Apropo, dacă un raster este afișat de mai multe ori, această operație poate fi efectuată o singură dată, iar rezultatul său poate fi folosit de mai multe ori Al doilea pas - ștergerea suprafeței de primire - rămâne același În al treilea pas, se utilizează operația bitmap SRCPAINT în loc de SRCINVERT Ca rezultat, pâlpâirea ar trebui să fie redusă, deoarece numai pixelii din tranziția elipsei de la culoarea originală la negru și apoi sunt înlocuiți cu pixelii sursă Pentru a elimina complet pâlpâirea, toate ieșirile trebuie efectuate pe un bitmap în afara ecranului și apoi copiate pe ecran Ieșire transparentă folosind decuparea Dacă masca are o formă geometrică simplă, o ieșire transparentă fără pâlpâire este ușor de realizat folosind regiunea de tăiere Din păcate, programatorii subestimează adesea capacitățile de tăiere a regiunilor, în principal pentru că suportul pentru regiuni în interfața GDI pe biți a lăsat mult de dorit Următoarea funcție generează un raster oval folosind o operație simplă de blitting folosind o regiune de tăiere BOOL CIPOvalStretchDIBits(HDC hDC, int XDest int YDest, int nDestWidth, int nDestHeight, int XSrc, int YSrc int nSrcWidth int nSrcHeight, const void *pBits, const BITMAPINFO *pBMI, UINT iUsage) { RECT rect = { XDest YDest, XDest + nDestWidth YDest + nDestHeight }; LPtoDP(hDC (PUNCTUL *) & rect ); HRGN hRgn = CreateEl ipticRgnlndirect(& rect); Transparență fără mască SaveDC(hDC); SelectCl pRgn(hDC, hRgn); DeleteObject(hRgn): BOOL rslt = StretchDIBits(hDC, XDest, YDest, nDestWidth, nDestHelght, XSrc YSrc nSrcWidth, nSrcHeight, pBits, pBMI, IUsage, SRCCOPY); RestoreDC(hDC, - ); return rslt; Probabil că merită să ne amintim câteva fapte despre lucrul cu regiuni și tăiere Regiunile de tăiere sunt definite în coordonatele dispozitivului, nu în coordonatele logice Prin urmare, înainte de a crea o regiune prin apelarea CreateEl ipticRgnIndirect, funcția CIipOvalStretchDIBits trebuie mai întâi să mapeze dreptunghiul de recepție la sistemul de coordonate al dispozitivului din contextul de recepție Pretratarea imaginii În unele situații, un bitmap transparent ar trebui să fie afișat numai pe suprafețe cu o culoare uniformă de fundal De exemplu, hărțile de biți ale comenzilor de meniu sunt afișate de obicei pe un fundal de meniu a cărui culoare uniformă este determinată de configurația curentă a sistemului Pentru a asigura o eficiență maximă atunci când lucrați cu astfel de imagini, ar trebui să pregătiți imaginea în forma finală înainte de scoatere API-ul Win are o caracteristică extrem de utilă care ajută la această sarcină: HANDLE LoadlmageCHINSTANCE hinst, LPCTSTR IpszName, UINT uType, int cxDesired, int cyDesired, UINT fuLoad); Funcția LoadImage încarcă cursoarele mouse-ului, pictogramele și hărțile de biți din resurse sau fișiere externe Cursorele și pictogramele pot fi setate la dimensiunea dorită Pentru rastere, Loadlmage poate crea o secțiune DDB sau DIB Mapând unele dintre culorile unei imagini cu alte culori, puteți pregăti imaginea pentru ieșire Când este încărcat dintr-o resursă, primul parametru specifică mânerul instanței modulului; în acest caz, parametrul IpszName specifică numele resursei De asemenea, poate specifica numele unui fișier extern dacă steag-ul LR LOADFROMFILE este trecut în parametrul fuLoad Parametrul uType poate fi IMAGE BITMAP, IMAGE CURSOR sau IMAGE-ICON (pentru hărți de biți, cursoare de mouse și, respectiv, pictograme) Perechea cxDesired/cyDesired este utilizată numai pentru a determina dimensiunile dorite ale cursorului sau pictogramei Ultimul parametru, fuLoad, controlează procesul de conversie De exemplu, indicatorul LR CREATEDIBSECTION specifică faptul că o secțiune DIB trebuie creată în loc de un DDB Indicatorul LR L ADMAP DC L RS mapează pixelii cu RGBC , , ) la COLORJDSHADOWS, RGB( , , ) la C L R DFACE și RGBC , , ) la C L R DLIGHT Când este specificat steag-ul LR MONOCHROME, rasterul este încărcat în format alb-negru Steagul LR TRANSPARENT mapează pixelii a căror culoare se potrivește cu culoarea primului pixel al imaginii cu culoarea de fundal a sistemului ferestrei Capitolul GEAMURA DE CULOARE Indicatorul LR VGACOLOR necesită ca bitmaps-ul să utilizeze culori VGA Consultați documentația MSDN pentru detalii Dintre aceste steaguri, LR TRANSPARENT este cel mai interesant Când acest indicator este setat, Loadlmage înlocuiește pixelii care se potrivesc cu culoarea primului pixel din imagine cu COLOR WINDOW Prin urmare, dacă un raster este afișat pe un fundal COLOR WINDOW, ieșirea întregului raster cu cea mai simplă operație SRCCOPY va avea același efect ca ieșirea unui raster cu o mască aplicată Cu toate acestea, această caracteristică poate fi utilizată numai dacă bitmap-ul folosește o paletă și este afișată pe fundalul culorii sistemului COLOR WINDOW De ce nu există nicio funcție în GDI care să vă permită să atribuiți o culoare arbitrară ca transparentă? Următorul fragment arată cum să utilizați funcția Loadlmage pentru a încărca o serie de imagini și a crea o animație simplă Utilizăm imaginea țânțarilor din SDK-ul DirectX Secvența de animație constă din trei imagini cu poziții diferite ale picioarelor și aripilor Când se afișează secvențial rasterele cu un mic decalaj, apare o iluzie de mișcare void TestLoadImage (HDC hDC, HINSTANCE hlnstance) HBITMAP hBitmap[ ]: const nlD[] = { IDB-MOSQUITl IDB M SQUIT , IDB M SQUIT }: pentru (Int = : i = ; ) // Alfa / , / , / , / / BLENDFUNCTION amestec = { AC SRC OVER, , / }; Dacă ( ! AlphaBlend(hDCDst, XDst YDst nDstW nDstH, hDCSrc, YSrc YSrc, nSrcW, nSrcH, amestec): returnează TRUE; } Funcția AlphaFade îmbină rasterul sursă pe suprafața de destinație în cinci pași, cu valori alfa de / , / , / , / și / După prima ieșire, o parte a imaginii este deja prezentă în receptor, astfel încât coeficienții acumulați vor fi / , / , / , / și în final / ferestre transparente Windows / a introdus un nou stil de fereastră extinsă Când steag-ul WS EX LAYERED este setat, toate ieșirile în fereastră, în loc de ieșirile directe către ecran, sunt stocate în cache într-un bitmap care are aceeași dimensiune cu ecranul Conținutul acestui raster poate fi apoi afișat folosind o suprapunere alfa Aplicația poate chiar seta o cheie de culoare pentru o astfel de fereastră Toți pixelii a căror culoare se potrivește cu culoarea tastei vor fi transparenți, adică Capitolul I Utilizări non-triviale ale rasterelor pixelii de sub fereastră vor fi vizibili printre ei Când pe ecran apar porțiuni închise anterior ale unei ferestre cu stilul WS EX LAYERED, nu este necesară redesenarea aplicației - GDI pur și simplu reafișează conținutul bitmap-ului din cache Când este implementat corect, acest stil vă permite să creați noi efecte vizuale și să îmbunătățească performanța cu prețul stocării bitmap-urilor din cache Stilul WS EX LAYERED este specificat fie când este apelat CreateWIndowEx, fie mai târziu cu SetWindowLong După crearea unei ferestre, puteți seta o valoare alfa constantă pentru fereastră și o cheie de culoare opțională folosind funcția SetLayeredWindowAttri butes: BOOL SetLayeredW ndowAttributes(HWND hWnd, COLORREF crKey BYTE bAlpha, DWORD dwFlags): Parametrul hWnd conține mânerul ferestrei cu steag de stil WS EX LAYERED Parametrul dwFlags conține unul sau ambele steaguri LWA COLORKEY și LWA ALPHA Când se utilizează indicatorul LWA COLORKEY, parametrul crKey specifică cheia de culoare a transparenței Pentru indicatorul LWA ALPHA, parametrul bAI pha specifică factorul alfa constant al sursei Stilul WS EX LAYERED poate fi folosit numai pentru ferestrele de nivel superior Următorul fragment arată cum să creați o fereastră cu stilul WS EX LAYERED într-o funcție de fereastră: comutator(uMsg) { caz WM CREATE: mJiWnd = hWnd; SetWindowLong(m hWnd GWLJXSTYLE GetWindowLong(m hWnd GWLJXSTYLE) | WS EX LAYERED); SetLayeredWindowAttributes(m hWnd, RGB( , , ), OxCO, LWA ALPHA | LWA COLORKEY ): returnează : În acest fragment, funcția GetWindowLong returnează steagurile de stil extinse curente, care, atunci când sunt îmbinate cu WS EX LAYERED, sunt scrise înapoi în poziția lor inițială Apelarea SetLayeredWindowAttri butes setează factorul alfa la , ( xCO/ ) și cheia de culoare RGB ( ), o culoare ușor neobișnuită care este foarte apropiată de negru Execuția acestui fragment afectează semnificativ aspectul ferestrei Aproape toate ieșirile dintr-o fereastră, inclusiv ferestrele copil, devin translucide, deși mult mai lent Cu toate acestea, meniurile sau casetele de dialog rămân opace Pe fig prezintă un exemplu - o fereastră cu un raster DIB suprapus pe codul sursă al programului din MSVC IDE Vă rugăm să rețineți: desenul a fost obținut prin salvarea întregului ecran Dacă salvați numai conținutul ferestrei, în loc de o imagine de ecran, obțineți numai conținutul bitmap-ului din cache Așa cum se întâmplă de obicei cu noile tehnologii, ferestrele transparente apar mult mai încet decât ferestrele normale De asemenea, este frustrant faptul că meniurile sunt opace și ferestrele nu se redesenează corect Alpha Overlay y - pBMI->bm Header blHeight - - y; BYTE * D - pBItsDst + GetOffset(pBMIDst, dx, j + dy); BYTE * S - pBItsSrc + GetOffset(pBMISrc, sx, j + sy); Orez fereastra transparenta Canal alfa: clasa AirBrush Toate exemplele de mai sus folosesc o valoare alfa constantă aplicată fiecărui pixel din rasterul sursă Posibilitățile coeficienților alfa constanți sunt limitate De exemplu, nici măcar nu fac față sarcinii de ieșire transparentă a rasterelor, care este ușor de rezolvat folosind o mască Rasterul masca poate fi considerat ca un canal alfa codificat pe bit/pixel separat de rasterul principal Să aruncăm o privire la câteva utilizări tipice pentru canalele alfa Deși funcția de final AlphaBl vă permite să selectați atât secțiunile DDB, cât și DIB într-un context de dispozitiv compatibil, puteți lucra numai cu secțiuni DIB atunci când utilizați canale alfa Acest lucru se datorează faptului că în modurile de ecran care nu utilizează codificarea culorilor pe de biți, harta de biți DDB pe de biți nu va fi compatibilă cu contextul ecranului dispozitivului Într-o secțiune DIB de de biți, fiecare pixel este stocat în octeți Primii trei octeți conțin de obicei datele canalului albastru, verde și roșu, iar ultimul octet stochează canalul alfa AlphaBl end este singura funcție care citește și scrie date de canal alfa, așa că GDI nu ajută cu adevărat la pregătirea acestor date Când utilizați amestecarea alfa la nivel de pixel individual, AlphaBl final presupune că pixelii sursă au fost pre-multiplicați cu un factor alfa Prin urmare, pentru a folosi canalul alfa, trebuie să avem acces direct la pixelii secțiunii DIB Capitolul I Utilizări non-triviale ale rasterelor Editorii grafici moderni acceptă de obicei diferite tipuri de pensule (a nu se confunda cu pensulele GDI!), concepute pentru a desena puncte mari și linii groase O pensulă din editorul grafic este definită de forma, culoarea, orientarea, duritatea și alte atribute complexe De exemplu, o pensulă rotundă colorată cu o duritate de % este destul de comună, o caracteristică care determină viteza cu care pixelii pensulei se schimbă de la o culoare uniformă în centru la o culoare complet transparentă pe perimetru Când desenați puncte sau linii cu o astfel de perie, marginile lor se îmbină fără probleme cu fundalul fără formarea de contururi clare, ca în desenul standard GDI Efectul descris poate fi reprodus cu ușurință folosind canalul alfa Listarea arată clasa KAirBrush implementată în secțiunea DIB Lista Clasa KAirBrush clasa KAirBrush { HBITMAP m hBrush; HDC m hMemDC; HBITMAP m h d; int m nWidth; int mjiHeight; void Eliberare (void) { SelectObject(m hMemDC m h d); DeleteObject(m hMemDC); DeleteObject(m hBrush); m h d = NULL; mJiMemDC=NULL: mJiBrush=NULL; } public: KAirBrush() { m hBrush = NULL; m hMemDC=NULL: m h d = NULL; } -KAirBrush() { EliberareO; } void Create(int width int height COLORREF culoare); void Apply(HDC hDC, int x int y); ): void KAirBrush::Apply(HDC hDC, int x, int y) { amestec BLENDFUNCTION » { AC SRC OVER, , AC SRC ALPHA }: Alpha Overlay AlphaBlend(hDC x-m nWidth/ y-m nHeight/ mjiWidth, mjiHeight mJiMemDC , , m nWidth, mjiHeight amestec); } void KAirBrush::Create (lățime int, înălțime int, culoare COLORREF) { ReleaseO: BYTE*pBiți: BITMAPINFO Bmi = { { sizeof(BITMAPINFOHEADER) lăţime înălţime BI RGB } }; mJiBrush = CreateDIBSection(NULL & Bmi DIB RGB COLORS (void **) și pBiți NUL NUL): mJiMemDC = CreateCompatibleDC(NULL): m h d = (HBITMAP) SelectObject(mJiMemDC mJiBrush); mjiWidth = lățime; mjiHeight=înălțime: // Cerc uniform colorat pe fundal alb { PatBlt(mJiMemDC, latime inaltime ALB): HBRUSH hBrush = CreateSolidBrush(culoare): SelectObject(mJiMemDC hBrush): SelectObject(mJiMemDC GetStockObject(NULL PEN)): El lipse(mJiMemDC lățime înălțime): SelectObject(mJiMemDC GetStockObject(WHITE BRUSH)): DeleteObject(hBrush): BYTE * pPixel = pBiți: // Calculați canalul alfa și înmulțiți valorile pixelilor pentru (int y= ; y bmiHeader biHeight > ) // Pentru Bitmap inversat y = pBMI->bmiHeader biHeight - - y: return ( pBMI->bmiHeader biWidth * pBMI-> Antet IMC bi BitCount + )/ * *y + ( pBMI->bmiHeader biBitCount / ) * x; } // Amestecare alfa între două hărți de biți DIB pe de biți BOOL AlphaBlend (BITMAPINF * pBMIDst BYTE * pBitsDst int dx, int dy, int w, int h, Continuare & Capitolul Lista Continuare BITMAPINFO * pBMISrc, BYTE * pBitsSrc, Int sx int sy amestec BLENDFUNCTION) { int alpha = blend SourceConstantAlpha; // Alfa constantă int beta = - alfa: format int; if ( blend AlphaFormat== ) format= ; else if ( alfa== ) format= ; altfel format= : pentru (int j= ; j =m nWidth) ) întoarcere - ; dacă ( (y =m nÎnălțime) ) returnează - : BYTE * pPixel s m pOrigin + y * m nDelta; comutare ( m nlmageFormat ) { cazul DIB- BPP: return ( pPixel[x/ ] » ShiftlbppW ] ) și x : Acces direct la pixeli caz DIB BPP: return ( pPixel[x/ ] » Shlft bpp[x% ] ) & x ; caz DIB BPP: return ( pPixel[x/ ] » Shlft bppEx% J ) & OxOF: caz DIB BPP: returnează pPixel[x]: cazul DIB RGB : caz DIB RGB : return ((WORD *)pP xel)[x]; caz DIB RGB ; pPixel += x * ; return (pPixel[ ]) | (pPixel[ ] « ) | (pPixel[ ] " ); caz DIB RGB ; caz DIB RGBA : returnare ((DWORD *)pP xel)[x]; întoarcere - ; BOOL KDIB;;SetPixelIndex(Int x, Int y DWORD Index) { Dacă ( (x =m nW dth) ) returnează FALSE; Dacă ( (y =m nHe ght) ) returnează FALSE; BYTE * pPixel = m p r g n + y * mjiDelta; swltch ( m nImageFormat ) cazul DIB BPP; pPixel[x/ ] = (BYTE) ( ( pPixel[x/ ] & Masklbpp[x£ ] ) | ( (Index & ) « Shlftlbpp[xX ] ) ); pauză; cazul DIB BPP: pPixel[x/ ] = (BYTE) ( ( pPixel[x/ ] & Mask bpp[x£ ] ) | ( (Index & ) « Shlft bpp[xM] ) ); pauză; cazul DIB BPP: pPixel[x/ ] = (BYTE) ( ( pPixel[x/ ] & Mask bpp[x£ ] ) | ( (Index & ) « Shlft bpptx% ) ); pauză: cazul DIB BPP: pPixel[x] = (BYTE) Index: break; Continuare Capitolul Lista - Continuare case DIB RGB : case DIB RGB : ((WORD *)pPixel)[x] = (WORD) Index; pauză: cazul DIB RGB : ((RGBTRIPLE *)pP xel)[x] = * ((RGBTRIPLE *) & index); pauză; cazul DIB RGB : cazul DIB RGBA : ((DWORD *)pPixel)[x] = index; pauză; Mod implicit: returnează FALSE; } returnează TRUE: } Funcțiile oferă verificarea limitelor Deoarece în afara limitelor rezultă de obicei GPF-uri (Erori generale de protecție), oprim imediat astfel de încercări Dacă coordonatele sunt în afara limitelor rasterului, funcția returnează un cod de eroare După verificarea parametrilor, funcția calculează adresa primului pixel al liniei de scanare la coordonata y, folosind adresa începutului logic al rasterului și diferența dintre adresele de început a două linii de scanare adiacente Aceste două caracteristici sunt calculate în avans, ținând cont de ordinea (înainte sau înapoi) a liniilor de scanare din DIB De exemplu, pentru rasterele DIB standard cu linii de scanare inversate, începutul logic al DIB este la sfârșitul datelor raster, iar offset-ul liniilor de scanare este o valoare negativă La accesarea directă a pixelilor se ia în considerare formatul acestora Pentru hărțile de biți cu codificare de , și biți/pixel, fiecare pixel ocupă doar o fracțiune de octet, așa că programul trebuie să calculeze deplasarea biților și să construiască masca Cel mai simplu mod de a lucra cu rastere de biți, în care fiecare pixel ocupă exact un octet Într-un raster de biți, un pixel ocupă doi octeți Apelantul trebuie să convertească în mod independent datele pixelilor pe biți în RGB Cu hărțile de biți pe de biți, lucrurile sunt mai complicate, deoarece nu ne putem referi la un pixel de de biți ca un DWORD și să mascam cei biți superiori Deși există programe ocazionale în literatura de programare care implementează această abordare, este de fapt inacceptabilă De exemplu, atunci când se creează o secțiune x DIB pe de biți, dimensiunea matricei de pixeli va fi de x x = KB Pe procesoarele Intel vor fi alocate exact trei pagini de memorie Offset-ul ultimului pixel din raster este x FFD Dacă încercați să-l citiți ca DWORD, procesorul va depăși cu octet blocul de kilobyte, ceea ce va duce cel mai probabil la un GPF Metoda SetPixel Index are aproape aceeași structură ca și GetPixel Index Pentru hărțile de biți de , și biți, atribuirea unui pixel este redusă la ștergere Transformări raster afine biții săi originali folosind o mască și adăugând date noi Pentru hărți de biți pe de biți, pointerul este convertit într-un tip de pointer RGBTRIPLE și datele sunt copiate ca structură RGBTRIPLE, astfel încât compilatorul să genereze cod pentru a copia exact trei octeți Efectuați operațiuni raster care necesită acces aleatoriu la pixeli, cum ar fi rotații, oglindire sau copierea datelor între rasterele de același format? Funcțiile GetPixel Index și SetPixel Index sunt exact ceea ce aveți nevoie Aceste funcții funcționează foarte bine și pentru hărți de biți fără palete Dacă doriți să colorați un pixel cu roșu raster de biți/pixel, va trebui să verificați în prealabil tabelul de culori Vom reveni la acest subiect mai târziu Transformări raster afine Utilizarea metodelor GetPixel Index și SetPixel Index create în secțiunea anterioară este cel mai bine ilustrată printr-un exemplu concret Să încercăm să implementăm un algoritm general pentru transformările raster afine În general, am îndeplinit deja principiile de bază pentru rezolvarea acestei probleme atunci când simulăm funcția PlgBlt Lista prezintă două funcții: KDIB: :PlgBlt și KDIB: :TransformBitmp Funcția KDIB: :PlgBlt convertește un dreptunghi în interiorul unui raster DIB într-un paralelogram în interiorul altui raster DIB Un paralelogram este definit de trei puncte de pe suprafața receptoare Funcția KDIB::PlgBlt, ca și funcția GDI cu același nume, acceptă orice transformare afină bidimensională, inclusiv deplasare, oglindire, rotații și deplasări Structura KDIB::PlgBlt este similară cu imitația noastră a funcției GDI PlgBlt, dar în loc de funcțiile lente GDI GetPixel și SetPixel, folosește funcțiile GetPixel Index și SetPixel Index pentru a lucra cu pixeli Lista Transformări raster afine generale BOOL KDIB::PlgBlt(const POINT * pPoint KDIB * pSrc int nXSrc int nYSrc int nWidth int nHeight) { Harta KReverseAffine(pPoint): map Setup(nXSrc, nYSrc nWidth nHeight): pentru (int dy-map miny: dy =nXSrc) && (sx "nYSrc) && (sy GetPixelIndex( ( int)sx (int)sy)): } Continuare & Capitolul Lista Continuare returnează TRUE: } HBITMAP KDIB::TransformBitmap(XFORM * xm COLORREF crBack) IntxO yO, xl, yl x , y , x y : Hartă (xm, xO yO); // Hartă (xm m nWidth xl yl): // Hartă(xm, , mjiÎnălțime, x y ): // Hartă(xm mjiWidth, mjiHeight, x y ): intxmin xmax; Int ymin ymax; minmax(x xl x x xmin, xmax); minmax(y , yl, y y ymin ymax): int destwidth = xmax - xmin; int destheight = ymax - ymin: KBitmapInfo deșt; deșt SetFormat(destwi dth desthei ght m pBMI->bmiHeader biBitCount m pBMI->bmiHeader biCompression); BYTE*pBits; HBITMAP hBitmap = CreateDIBSection(NULL dest GetBMK) DIB RGB COLORS, (void **) & pBits, NULL, NULL); if ( hBitmap==NULL ) returnează NULL; { HDC hMemDC = CreateCompatibleDC(NULL); HGDIOBJ hold = SelectObject(hSMemDC, hBitmap): HBRUSH hBrush = CreateSolidBrush(crBack); RECT rect = { destwidth dimensiune }: Fi Rect(hMemDC, & rect hBrush); DeleteObject(hBrush); SelectObject(hMemDC Hold); DeleteObject(hMemDC); } KDIB destDIB; destDIB AttachDIB(dest GetBMK) pBiți, ): PUNCTUL P[ ] = { { x -xmin y -ymin }, { xl-xmin yl-ymin}, {x -xmin y -ymin } }; destDIB PIgBlt(P this, , , mjiWidth, mjiHeight): returnează hBitmap; Transformări raster afine Funcția KDIB::PlgBlt presupune că a fost creat în prealabil un raster țintă de dimensiunea necesară, al cărui format de pixeli se potrivește cu formatul rasterului sursă O transformare raster generează de obicei un nou raster de o dimensiune diferită Rotațiile și translațiile creează colțuri care trebuie umplute cu culoarea de fundal, deoarece se află în afara imaginii convertite Funcția KDIB::TransformBitmap este responsabilă pentru „pregătirea scenei” - pentru apelarea KDIB::PlgBlt Când este apelat, i se transmite o matrice de transformare și o culoare de fundal Pe baza formatului raster DIB curent, funcția calculează dimensiunea exactă a rasterului convertit și creează o secțiune DIB de dimensiunea corespunzătoare cu formatul raster actual Înainte de a trece funcția KDIB: -PlgBlt pentru conversie directă, secțiunea DIB creată este umplută cu o culoare de fundal Pe fig Figura prezintă o imagine cu culori rotite cu ° de către funcția KDIB::PlgBlt Orez Rasterele rotative cu KDIB: :PlgBLt Pe un computer cu un procesor Pentium de MHz relativ slab, funcția KDIB:- PlgBlt calculează rotația unei imagini de x , bpp în secunde; Se dovedește , megapixeli pe secundă Dacă, spre comparație, apelurile către GetPixel Index/SetPixel Index sunt înlocuite cu apeluri către funcțiile GetPixel/SetPixel GDI, timpul de procesare crește la , secunde ( , megapixeli pe secundă) Experimentul demonstrează clar că accesul direct la pixeli funcționează mult mai rapid decât funcțiile GDI GetPixel/SetPixel Având în vedere că funcția KDIB: -PlgBlt utilizează calcule reale, câștigul de performanță este chiar mai mare de ori Capitolul Transformări raster specializate rapide Când viteza este în prim-plan, algoritmii generali trebuie optimizați pentru situații specifice Specializarea este importantă în special pentru algoritmii grafici, cum ar fi transformarea imaginii Dacă doriți să scrieți funcții personalizate pentru diferite formate DIB, puteți codifica operațiunile cu pixeli ale unui anumit format DIB „în loc”; acest lucru vă va permite să scăpați de supraîncărcarea apelării unei funcții în bucla interioară, verificarea formatului raster, calculul dublu al adreselor pixelilor etc Optimizarea este posibilă și în domeniul calculelor reale pentru maparea coordonatelor rasterului receptor la coordonatele sursei Implementarea standard a conversiilor reale în numere întregi este foarte lentă, deoarece implică un apel de funcție Lista prezintă o funcție de conversie raster care nu utilizează calcule reale și funcționează doar cu rastere de de biți Funcția PlgBlt începe în același mod ca PlgBlt - prin pregătirea transformării inverse de la chiuvetă la sursă Funcția KReverseAffine: -Setup returnează caseta de delimitare a suprafeței de recepție, care este apoi comparată cu dimensiunile rasterului de recepție pentru a se asigura că valorile rezultate sunt corecte Parametrii casetei de delimitare sursă sunt convertiți în format de virgulă fixă prin înmulțirea cu o constantă FACTOR de Aceeași operație este apoi efectuată pe matricea de transformare În acest caz, se utilizează un format în virgulă fixă, constând dintr-un număr întreg de biți și o parte fracțională de biți Această reprezentare vă permite să lucrați cu rastere mari și oferă suficientă precizie Lista Funcție de conversie optimizată Rastere DIB pe de biți BOOL KDIB::PIgBlt (const POINT * pPoint KDIB * pSrc int nXSrc, int nYSrc, int nWidth, int nHeight) { // Multiplicator pentru a trece de la FLOAT la formatul punct fix const int FACTOR = ; // Generați transformarea inversă de la receptor la sursă Harta KReverseAffine(pPoint): tar Setup(nXSrc, nYSrc, nWidth, nHeight); // Asigurați-vă că aparține limitelor rasterului de destinație dacă ( map minx mjrWidth ) map maxx = mjrWidth; if ( map miny mjiHeight ) map maxy = m nHeight; // Dreptunghi sursă în format punct fix Transformări raster specializate rapide int sminx = nXSrc * FACTOR; int sminy = nYSrc * FACTOR; int smaxx = ( nXSrc + nWidth ) * FACTOR; int smaxy = ( nYSrc + nHeight ) * FACTOR; // Matrice de transformare în format punct fix int mll = (int) int ml = (int) int m = (int) int m = (int) int mdx = (int) int mdy = (int) (map m xm eMll * FACTOR); (map m xm eM * FACTOR); (map m xm eM * FACTOR); (map m xm eM * FACTOR); (map m xm eDx * FACTOR); (map m xm eDy * FACTOR): BYTE * SOrigin = pSrc->m pOrigin; int SDeita = pSrc->m nDelta; // Buclă prin liniile de scanare ale rasterului de recepție pentru (int dy=map miny; dy =sminx) && (sx =sminy) && (sy bool ColorTransform (KDIB * dib, hartă simulată) { // Tabel de culori OS/ DIB: -, -, bpp, compresie RLE dacă ( dib->m pRGBTRIPLE ) { pentru (int i= : i m nCl rllsed: i++) map(dib->m pRGBTRIPLE[i] rgbtRed, dib->m pRGBTRIPLE[i] rgbtGreen, dib->m pRGBTRIPLE[i] rgbtBlue): returnează adevărat; } // Tabel de culori Windows DIB: -, -, bpp, compresie RLE dacă (dib->m pRGBQUAD) { pentru (int i= ; i m nClrllsed; i++) map(dib->m pRGBQUAD[i] rgbRed, dib->m pRGBQUAD[i] rgbGreen, dib->m pRGBQUAD[i] rgbBlue); returnează adevărat: } pentru (int y= ; y m nHeight; y++) { int width = dib->m nWidth; unsigned char * pBuffer = (unsigned char *) dib->m pBits + dib->m nBPS * y; comutați ( dib->m nImageFormat ) { case DIB RGB : // format RGB pe biți, - - pentru (; lățime> : lățime ) { BYTE roșu = ( (* (WORD *) pBuffer) & x ) » ; BYTE verde = ( (* (WORD *) pBuffer) & xOSEO ) » : BYTE albastru = ( (* (WORD *) pBuffer) & OxOOlF ) " : harta (rosu, verde, albastru); * ( CUVÂNT *) pBuffer = ( ( roșu » ) « ) | ( ( verde " ) " ) | (albastru" ): pTampon += ; Continuare^ Capitolul Lista Continuare } pauză; carcasă DIBJ RGB : // format RGB pe biți, - - pentru (; lățime> ; lățime ) BYTE roșu = ( (* (WORD *) pBuffer) & xF ) » : BYTE verde = ( (* (WORD *) pBuffer) & x E ) » ; BYTE albastru = ( (* (CUVENT *) pBuffer) & OxOOlF ) « ; harta( rosu, verde, albastru); * ( CUVÂNT *) pBuffer = ( ( roșu » ) « ) | ( ( verde » ) « ) | ( albastru " ): pBuffer += ; } pauză; case DIB RGB : // format RGB pe de biți pentru (; lățime> ; lățime ) { map( pBuffer[ ], pBuffer[l], pBuffer[ ] ); pTampon += ; } pauză; case DIB RGBA : // format RGBA pe de biți case DIB RGB : // format RGB pe de biți pentru (; lățime> ; lățime ) { map( pBuffer[ ], pBuffer[l], pBuffer[ ] ); pBuffer += : } pauză; implicit: returnează fals; } } returnează adevărat; } Funcția ColorTransform ia doi parametri: un pointer către o instanță KDIB și un pointer către o funcție Desigur, trecerea unui pointer către o funcție fără a seta mai întâi prototipul pare puțin ciudat, dar evident că această metodă este acceptată și utilizată în STL Prima parte a funcției procesează tabelele de culori ale fișierelor BMP în format OS/ : fiecare structură RGBTRIPLE este procesată prin apelarea funcției de conversie a culorilor (parametru, hartă) Funcția de conversie a culorii preia trei parametri (canal roșu, verde și albastru) ca referință și returnează culoarea convertită în aceleași variabile Fragmentul de tabel de culori Windows arată similar, cu excepția faptului că de data aceasta este folosită structura RGBQUAD Conversii de culoare Această parte a codului gestionează toate formatele DIB paletate, inclusiv formatele RLE comprimate și necomprimate Codul rămas se ocupă de hărți de biți True Color pe biți, High Color, pe și de biți cu canale alfa Ordinea logică a matricei de pixeli nu contează în acest caz, deoarece programul pur și simplu iterează peste pixeli în ordinea în care sunt localizați în memorie Pentru hărți de biți pe biți, sunt acceptate două formate comune Programul trebuie să extragă canalele RGB, să le convertească pe fiecare la o valoare de biți, să apeleze funcția de conversie a culorii și apoi să împacheteze rezultatul înapoi într-un cuvânt de biți Cu rasterele pe de biți, totul este destul de simplu Într-un bitmap pe de biți, canalul alfa rămâne neschimbat Toate celelalte formate DIB exotice (cum ar fi imagini JPEG sau PNG încorporate sau hărți de biți cu câmpuri de biți non-standard) nu sunt acceptate de implementarea curentă a funcției ColorTransform Conversia bitmaps în tonuri de gri Convertirea culorilor din spațiul RGB în tonuri de gri se face de obicei folosind formula: Gri = , x Roșu + , x Verde + , x Albastru Într-o implementare pe computer, am dori să facem fără calcule în virgulă mobilă Următoarea este o metodă (bazată pe șablonul ColorTransform) pentru a converti un raster RGB în tonuri de gri // , * roșu + , * verde + , * albastru Inllne void MaptoGray (BYTE și roșu BYTE și verde, BYTE și albastru) roșu = ( roșu * + verde * + albastru * + ) / ; verde = roșu; albastru=rosu; } clasa Klmage: KDIB public { public; bool ToGreyScale(vold); }: bool Klmage::ToGreyScale(vo d) { return ColorTransform(th s MaptoGray): } Pentru a încapsula algoritmii de procesare raster dezvoltați în acest capitol, creăm o clasă Klmage care derivă din KDIB Clasa Klmage nu conține variabile suplimentare Dintre toate metodele acestei clase, doar metoda ToGreyScale este prezentată mai sus Vom adăuga mai multe metode la această clasă mai târziu Metoda Klmage::ToGreyScale convertește rasterul DIB de culoare curent în tonuri de gri Pentru a face acest lucru, apelează pur și simplu funcția de șablon ColorTransform și îi transmite o funcție de transformare a culorii MaptoGray Funcția MaptoGray, folosiți Capitolul folosind operații cu numere întregi, calculează luminozitatea culorii gri și o atribuie tuturor celor trei canale RGB În versiunea de depanare, MaptoGray este compilat ca o funcție separată, un pointer către care este transmis la ColorTransform În versiunea finală, toate apelurile către MaptoGray au fost înlocuite cu cod inline pentru performanță optimă Corecție gamma Imaginile afișate sunt supuse distorsiunii fotometrice din cauza răspunsului neliniar al ecranului monitorului la intensitatea semnalului Răspunsul fotometric al dispozitivului de ieșire se numește răspuns gamma Sistemele de operare diferite folosesc caracteristici gamma diferite pentru ecranul monitorului De exemplu, o imagine pregătită pe un Macintosh pare prea întunecată pe un computer Pe de altă parte, o imagine transferată de pe un server PC pe un Macintosh poate părea prea ușoară Pentru a compensa aceste diferențe, trebuie să ajustați caracteristicile gama ale dispozitivului Corecția gamma este de obicei efectuată independent pe toate cele trei canale RGB Trei matrice de de octeți sunt precalculate și transmise convertorului gamma software sau adaptorului video Fiecare matrice aparține unuia dintre canale Corecția gamma este ușor de implementat folosind funcția de șablon ColorTransform BYTE redGammaRamp[ ]: BYTE greenGammaRamp[ ]: BYTE blueGammaRamp[ ]; Inline void MapGamma (BYTE și roșu BYTE și verde BYTE și albastru) { roșu = roșuGammaRamptred]; verde = verdeGammaRampEgreen]; albastru = albastruGammaRampEblue]; } BYTE gamma (index dublu g int) return min( (int) ( ( * pow(index/ /g)) + ) ); } bool Klmage::GammaCorrect(double redgamma double greengamma double bluegamma) { pentru (int i= : i ; lățime ) Continuare # Capitolul Lista Continuare { BYTE index = ( ( pBuffer[O] & mask ) » shift ) & Oxl: if ( MapIndex(index) ) pBuffer[O] = ( pBtiffer[O] & ~ mask ) (( index & OxOF) " deplasare): masca "= : shift -= : daca (masca== ) { pBuffer++:mask= x ; shift = ; } } void KPIxelMapper::Map bpp(BYTE * pBuffer int width) { pentru (:width> :width ) MapRGB( pBuffer[ L pBuffer[l], pBuffer[O] ): pBuffer += : } } Toate metodele clasei principale sunt virtuale Metoda MapRGB este o funcție virtuală pură care procesează un singur pixel RGB Nu este implementat de clasa KPIxelMapper deoarece se așteaptă ca clasa derivată să ofere propria sa implementare pentru algoritmul selectat Metoda MapIndex operează pe pixeli într-un format de index de tabel de culori Implementarea noastră implicită convertește indicele de culoare într-o valoare RGB și apelează MapRGB Metodele Maplbpp, Map bpp, , Map bpp asigură procesarea liniei de scanare pentru toate formatele raster DIB comune Implementarea lor standard iterează peste toți pixelii din linia de scanare și apelează MapRGB sau MapIndex pentru fiecare pixel Toate aceste metode sunt scrise ca funcții virtuale, astfel încât clasa derivată le poate implementa în felul său De exemplu, o clasă derivată ar putea decide că imaginile pe de biți sunt deosebit de importante pentru ea, să înlocuiască Map Lpp și să înlocuiască apelurile către MapRGB cu cod inline pentru a obține cea mai bună performanță Rețineți că bucla interioară joacă un rol critic în performanță Lista arată două manere de scanare pentru formatul de biți și de biți Ambele funcții, MapRGB și MapIndex, returnează o indicație booleană că parametrii trecuți prin referință s-au modificat Pe baza valorii primite, apelantul poate decide dacă modifică pixelul original Pentru a folosi clasa KPIxelMapper pentru a transforma un raster DIB, creăm o nouă funcție, Klmage::PixelTransform, care ar trebui să creeze o instanță a clasei KPIxelMapper și să îi transmită linii de scanare Funcția Phihei -Transform este prezentată mai jos - după cum puteți vedea, este foarte simplă Conversia pixelilor în raster bool Klmage::P xelTransform(KP xelMapper & ball) { dacă ( m pRGBTRIPLE ) tar SetColorTable((BYTE *) m pRGBTRIPLE, sizeof(RGBTRIPLE), m nClrllsed); else if ( m pRGBQUAD ) tar SetColorTable((BYTE *) m pRGBQUAD, sizeof(RGBQUAD), m nClrUsed); pentru (int y= ; y bmiHeader biSize = slzeof(BITMAPINFOHEADER): pNewDIB->bmiHeader biWidth = dib GetWidthO: pNewDIB->bmiHeader biHeight = dib GetHeightO: pNewDIB->bmiHeader biPIanes = : pNewDIB->bmiHeader biBitCount = : pNewDIB->bmiHeader biCompression = BI RGB: pentru (int c= : c bm Colors[c] rgbRed = c: pNewDIB->bmiColors[c] rgbGreen = c: pNewDIB->bmiColors[c] rgbBlue = c; } m pBits = (BYTE*) & pNewDIB->bmiColors[ ]; dacă (pNewDIB==NULL) returnează NULL: dib P xelTransform(* this): returnează pNewDIB: } BITMAPINFO * Klmage::SplitChannel (operator operator) { canal canal: canal de întoarcere Split(* this, opera): } Clasa KChannel derivă din KPIxelMapper Locul central în acesta este ocupat de metoda Split, care primește o referință la DIB și Operator Metoda Split creează un bitmap DIB de de culori care are aceeași dimensiune ca și harta de biți sursă, completează paleta în tonuri de gri și stochează adresa matricei de pixeli în variabila m pBits, care va fi utilizată atunci când iterați peste pixeli Metoda KDIB::PixelTransform este apoi apelată, iterând peste toți pixelii din raster, ceea ce duce în cele din urmă la un apel către KChannel::MapRGB Implementarea noastră MapRGB solicită operatorului să mapeze un pixel RGB la un octet și stochează valoarea rezultată ca valoarea pixelului rasterului de de culori care urmează să fie creat Metoda StartLine este apelată la începutul fiecărei linii de scanare, care Capitolul permite programului să seteze corect poziția de pornire a șirului de recepție Clasa funcționează cu un singur canal Pentru a procesa mai multe canale, trebuie fie să organizați procesarea secvențială, fie să utilizați o nouă implementare care creează mai multe rastere DIB de biți și primește un nou tip de operator care returnează mai multe rezultate simultan Exemplu de selecție a canalului Clasa KChannel este ușor de utilizat; tot ceea ce vi se cere este să oferiți funcția dorită Mai jos sunt câteva exemple de funcții pentru efectuarea de operațiuni comune în modelele RGB, CMYK și HLS // Evidențiați canalul roșu în RGB inline BYTE TakeRed (BYTE roșu BYTE verde, BYTE albastru) { întoarce roșu; } // Evidențiați componenta neagră în KCMY inline BYTE TakeK (BYTE roșu BYTE verde BYTE albastru) { // min( -roșu -verde -albastru) dacă ( roșu : i ) * pDst ++ - Kernel(pSrc++ dy); Continuare^ Capitolul Lista Continuare memcpy(pDst pSrc, m nHalf); } void KFilter::FIIter bpp(BYTE * pDst BYTE * pSrc int nWidth, int dy) { memcpy(pDst, pSrc m nHalf * ): pDst += m nHalf * : pSrc += m nJumătate * ; pentru (int i=nWidth - * m nHalf; i> ; ) { * pDst ++ = Kernel(pSrc++ , dy); * pDst ++ = Kernel(pSrc++ , dy); * pDst ++ = Kernel(pSrc++, dy); } memcpyipDst pSrc m nJumătate * ); } void KFilter::Filter bpp(BYTE * pDst, BYTE * pSrc, int nWidth int dy) { memcpy(pDst, pSrc, m nHalf * ); pDst += mjiJumătate * ; pSrc += m nJumătate * ; pentru (int i=nWidth - * m nHalf: i> ; i ) { * pDst ++ = Kernel(pSrc++, dy); * pDst ++ = Kernel(pSrc++, , dy); * pDst ++ = Kernel(pSrc++ dy); * pDst ++ = * pSrc++: // Copiați canalul alfa } memcpyipDst pSrc, m nHalf* ): } Clasa KFilter pare mult mai simplă decât clasa KPixelTransform, în principal pentru că funcționează numai cu hărți de biți în tonuri de gri pe biți, de biți și de biți Filtrele spațiale efectuează operații matematice pe pixeli care nu au o interpretare normală pentru imaginile cu palete În principiu, a fost posibil să se ofere suport pentru imagini pe și biți, dar acest lucru ar crește semnificativ volumul de muncă Clasa KFilter operează pe o imagine în tonuri de gri cu o singură bandă Imaginile pe și de biți sunt considerate ca o colecție de mai multe canale procesate independent unul de celălalt Funcția virtuală pură KFilter::Kernel definește modul în care funcționează un filtru spațial Pentru Kfilter::Kernel, un pixel este un octet în intervalul , care determină intensitatea canalului dat Funcția primește un pointer către pixelul curent și offset-urile următorilor pixeli din același rând și aceeași coloană Cunoscând aceste trei valori, implementarea Kernel se poate referi la oricare dintre pixelii adiacenți folosind operații simple de adunare și scădere Funcția returnează un octet care este scris în imaginea de ieșire de către apelant După cum puteți vedea, liniile de scanare pe și biți nu se potrivesc bine Filtre spațiale în acest model Variabila mjiHalf conține valoarea (Nl)/ , deci pentru filtrele x este de obicei Metodele Filter bpp, Filter bpp și Filter bpp gestionează cele trei tipuri de linii de scanare pe care le acceptăm: biți, de biți și de biți Aceștia primesc un indicator către liniile de scanare sursă și destinație, lățimea liniei de scanare în pixeli și offset-ul liniei următoare În fiecare linie de scanare, primul și ultimul mjiHalf pixeli sunt pur și simplu copiați Pixelii rămași sunt trecuți la metoda Kernel canal cu canal, iar rezultatele sunt scrise pe linia de scanare de recepție Funcțiile sunt declarate virtuale, astfel încât să poată fi redefinite în clase derivate O nouă metodă Klmage:: Spațial Fi Iter a fost adăugată la clasa Klmage pentru a trece un DIB la clasa KFilter Metoda creează o nouă matrice de recepție de pixeli, copiază primele și ultimele linii de scanare neprocesate în ea și apelează una dintre metodele de filtrare KFilter pentru a procesa liniile rămase În cele din urmă, vechea matrice de pixeli este înlocuită cu cea nouă Implementarea de mai sus poate fi modificată fie pentru a genera un nou raster, fie pentru a stoca rezultatul în matricea de pixeli procesate a sursei, astfel încât supraîncărcarea memoriei să nu depășească dimensiunea câtorva linii de scanare bool Klmage::Spațial Filter(KF ter & pFilter) { BYTE * pDestBits = BYTE nou[mjiImageSize]; if ( pDestBits==NULL ) returnează fals: pentru (int y= : y =filter GetHalf()) && (y Filter bpp(pDest pBuffer mjiWidth m nBPS): break: case DIB RGBA : // format RGBA pe de biți case DIB RGB : // format RGB pe de biți pFilter->Filter bpp(pDest pBuffer mjiWidth mjBPS): break: Mod implicit: șterge[]pDestBits: returnează fals: Capitolul altfel memcpy(pDest, pBuffer, m nBPS): } memcpy(m pBits, pDestBits, m nImageSize): array delete El pDestBits: returnează adevărat: } Un filtru spațial x este de obicei descris printr-o matrice x și o greutate Numerele matricei x sunt înmulțite cu valorile de culoare ale pixelilor corespunzători din bloc, iar suma este împărțită la greutatea totală Rezultatul poate depăși intervalul folosit pentru a stoca intensitatea canalului de culoare, așa că uneori rezultatul trebuie să fie trunchiat Unele filtre adaugă o constantă la rezultat înainte de trunchiere Următorul este un șablon pentru o clasă care acceptă filtre spațiale x cu greutate suplimentară și o constantă adăugată: șablon clasa K Filter: KFilter public { BYTE virtual KerneKBYTE * P, int dx, int dy) { int r = ( PE-dy-dx] * kOO + PE-dy] * kOl + PE-dy+dx] * k + P[ -dx] * klO + PEO] * kll + PE +dx] * kl + PE dy-dx] * k + PEdy] * k + PE dy+dx] * k ) / greutate + adăugați: dacă (checkbound) dacă ( r ) întoarce : întoarce r; } }: Clasa K F ter are parametri Primii nouă parametri definesc o matrice de coeficienți x , urmată de o pondere, o constantă de adăugat și un boolean care controlează verificarea limitelor În general, implementarea ar putea fi construită pe calcule reale - codul rămâne același, doar tipul de date se va schimba Cu toate acestea, în acest caz, va trebui să facem nouă înmulțiri în virgulă mobilă și să convertim numărul real într-un număr întreg Modelul K Filter îmbunătățește foarte mult performanța unui filtru spațial utilizând numai parametri întregi Lucrăm doar cu numere întregi și fiecare filtru primește propriul set de parametri șablon Din punctul de vedere al compilatorului, nouă înmulțiri și o împărțire sunt operații constante ușor optimizate Filtre spațiale Dacă indicatorul de verificare a limitelor nu este setat, compilatorul nu trebuie să genereze codul corespunzător În același timp, creșterea cantității de cod este minimă, deoarece este redefinită o singură funcție pentru fiecare filtru Să folosim clasele noastre pentru a defini câteva filtre spațiale și a vedea ce minuni pot face Filtre de netezire și ascuțire Pe fig după prima figura sursă arată rezultatele aplicării a trei filtre spațiale: netezire, netezire gaussiană și ascuțire (pentru claritate, scara este : ) Netezire I | * | | | | / nouă Orez Filtre de netezire și ascuțire Cele trei filtre prezentate în figură sunt definite după cum urmează: TCHAR szSmooth[] = T(„Smooth”): TCHAR szGuasianSmooth[] = T("GuasianSmooth"): TCHAR szSharpenlngt] = JT'Sharpening"); K F ter filter smooth; K F ter filter guasiansmooth: K F lter filter sharpening; Imaginea originală este afișată în stânga sus În dreapta acestuia, este afișat rezultatul aplicării filtrului de netezire Matricea sa x este toate și greutatea sa este Prin urmare, acest filtru atribuie o medie pixelului Capitolul valoarea pixelilor din blocul x Un filtru anti-aliasing se numește filtru trece-jos, deoarece păstrează porțiunile de frecvență joasă și filtrează distorsiunile de frecvență înaltă În special, poate fi folosit pentru a netezi linii, forme și hărți de biți rezultate de GDI Figura arată cum filtrul anti-aliasing maschează marginile zimțate ale imaginii originale După aplicarea filtrului anti-aliasing, pe marginile glifului apar pixeli gri Filtrul de netezire gaussian aparține și el categoriei filtrelor trece-jos În loc de o distribuție uniformă, acest filtru atribuie o greutate mai mare pixelului central Filtrele de acest tip pot fi definite și pentru raze mai mari; figura prezintă un filtru x Filtrul de claritate scade pixelii vecini din cel curent pentru a accentua tranzițiile din imagine Face parte din categoria filtrelor de înaltă frecvență, care pun în evidență componentele de înaltă frecvență ale imaginii și lasă părțile de joasă frecvență neschimbate Reglând greutatea pixelului central, puteți modifica gradul de claritate Pentru imaginea monocromă prezentată în figură, rezultatul aplicării filtrului de ascuțire este aproape imperceptibil Detectarea și eliberarea limitelor Pe fig arată rezultatele aplicării filtrului Laplace și a două filtre de relief Aceste filtre sunt definite după cum urmează: TCHAR szLaplasian[] TCHAR szEmbossl [] TCHAR szEmboss [] = T("Laplasian"); = T("Gofrare °"); = TC'emboss ° G): K F lter filter laplasian; K F ter fiIter embossl ; K F ter filter emboss ; Filtrul Laplace arată ca un filtru de trecere înaltă, dar generează o imagine complet diferită Filtrul Laplace aparține categoriei de filtre de detectare a marginilor cu coeficienți de matrice cu sumă zero Filtrul de îmbunătățire a marginilor înlocuiește zonele colorate uniform cu negru și zonele cu modificări cu o culoare care nu este neagră În exemplul prezentat, filtrul adaugă la fiecare canal, astfel încât un rezultat negativ să nu fie înlocuit cu zero Ca urmare a adăugării a , zonele colorate uniform devin gri Următoarele două filtre, numite filtre bump, convertesc o imagine color în tonuri de gri cu un fel de efect D Există un într-un colț al matricei filtrului de denivelări, iar un element în colțul opus este - Aplicarea unui filtru de denivelări poate fi considerată ca scăderea unei imagini compensate cu o anumită cantitate din originală Rezultatul este mărit cu pentru a muta punctul zero la mijlocul scării de gri Pozițiile relative ale pixelilor cu valoare- Filtre spațiale MI și - determină direcția selecției reliefului În exemplul nostru, sunt demonstrate două direcții În al doilea exemplu, rezultatul înmulțirii este împărțit la , astfel încât reliefarea imaginii este redusă Orez Îmbunătățirea marginilor și filtre de bump Relief °, % eu in | * I | | - | / + Filtre morfologice Pe fig Figura prezintă trei filtre spațiale noi: filtre de compresie și expansiune și un filtru de buclă Pentru a face rezultatul mai vizual, imaginile sunt afișate la o scară de : Acestea sunt așa-numitele filtre morfologice Ele diferă de filtrele anterioare pe baza unei combinații liniare de pixeli Filtrul morfologic folosește o matrice N x N pentru a verifica pixelii învecinați Rezultatul verificării determină culoarea pixelului situat în centru Filtrul de compresie generează negru numai dacă toți pixelii din bloc sunt negri În caz contrar, se generează alb Astfel, ca urmare a aplicării filtrului de compresie, zonele albe ale imaginii sunt extinse Filtrul de expansiune generează alb numai dacă toți pixelii din bloc sunt albi În caz contrar, se generează negru Astfel, ca urmare a aplicării filtrului de expansiune, zonele albe ale imaginii sunt îngustate Capitolul Orez Filtre morfologice Filtrul de contur comprimă mai întâi și apoi scade originalul din imaginea rezultată Pentru zonele colorate uniform, filtrul de contur generează negru ( ) deoarece imaginea comprimată se potrivește cu originalul Noii pixeli albi care rezultă din compresie rămân albi Rezultatul este un contur alb al imaginii originale pe un fundal negru Figura arată rezultatele aplicării tuturor celor trei filtre la o imagine monocromă a unui caracter text Negrul este culoarea primului plan, iar albul este culoarea fundalului, așa că atunci când stoarceți zonele albe de fundal cresc, iar zonele negre din prim plan scad Extensia are efectul opus În exemplul nostru, liniile literei „w” devin mai subțiri când sunt comprimate și mai groase când sunt extinse Filtrul de contur lasă un contur alb de litere Aceste filtre morfologice au fost create pentru a lucra cu imagini monocrome Când lucrați cu imagini color împărțite în mai multe canale în tonuri de gri, extinderea este simulată prin calculul minim și compresia prin calculul maxim Mai jos este implementarea noastră a filtrului de extensie Funcția KEroslon::Kernel găsește valoarea minimă din cei nouă pixeli ai unui bloc de x și o returnează apelantului Pentru imagini color, a fost, de asemenea, posibil să se calculeze valoarea minimă peste cei opt pixeli din jurul pixelului central și să se returneze media aritmetică a pixelului central și valoarea minimă ca rezultat în acest exemplu de realizare, efectul de expansiune este oarecum redus Pentru a crea un filtru de compresie, este suficient să calculați maximul în loc de minim // Minim - extinderea zonelor întunecate clasa KEroslon : KFilter public Rezultate inline void mai mic(BYTE &x BYTE y) { dacă ( y vvs*^- a - ■■«■■■■■■■■■■■■■ ■■■■■■■■■■■■■■■■ ■■yaavkninkpv» Și M M și eu și și și M it și th Și în e ■■■■■■ ■■' Orez Analiza modificărilor din paleta sistemului În figură, fereastra cu paleta de sistem este afișată în două stări Prima stare afișează paleta de sistem cu culori web (o culoare este duplicată) și nuanțe suplimentare de gri După lansarea unei aplicații cu un ecran de splash colorat, paleta se schimbă dramatic: cele de culori ale paletei de sistem s-au schimbat astfel încât paleta permite afișarea cât mai bine posibilă a ecranului de splash Paleta se schimbă adesea la pornirea și închiderea altor aplicații, chiar și atunci când comutați între ferestrele copil în aplicațiile MDI Culori statice Se pare că culorile de la începutul și de la sfârșitul paletei nu se schimbă niciodată Aceste două părți ale paletei stochează culorile statice ale sistemului rezervate de sistemul de operare pentru interfața cu utilizatorul Sistemul de operare Windows își rezervă de obicei de culori statice, deși acest lucru poate fi redus Funcția GetSystemPalettellse returnează un steag care indică numărul de culori statice utilizate de sistem Dacă se returnează SYSPAL-NOSTATIC, sistemul folosește două culori statice, alb și negru; dacă valoarea returnată este SYSPAL STATIC, sunt utilizate de culori statice Windows a introdus un nou flag SYSPAL, N STATIC , ceea ce înseamnă că nu există deloc culori statice rezervate Funcția SetSystemPalettellse modifică modul curent de culoare static folosind steagurile descrise mai sus Se folosesc culori statice Paleta de sistem Funcții API precum GetSysColor și SetSysColor Prin urmare, dacă o aplicație dorește să reducă numărul de culori statice la SYSPAL NOTSTATIC, trebuie să păstreze toate culorile curente ale sistemului, să modifice numărul de culori statice, să înlocuiască culorile sistemului cu propriile culori și apoi să restabilească culorile originale ale sistemului Numărul de culori statice ar trebui schimbat doar ca ultimă soluție De exemplu, dacă o aplicație „medicală” dorește să afișeze cele de nuanțe de gri ale unei imagini cu raze X în modul de de culori, va trebui să folosească modul SYSPAL NOSTATIC sau SYSPAL N STATIC Aranjamentul a de culori statice pare destul de curios Șaisprezece culori sunt preluate din paleta VGA de culori; încă patru sunt determinate de schema de culori curentă În tabel Tabelul listează culorile statice pentru două scheme de culori: tradiționale și Spruce (Molid în versiunea rusă de Windows) Tabelul Culori statice Index RGB Valoare Nume Aplicație implicită x x , x , x Negru C L R WIND WFRAME, C L R MENUTEXT, C L R WIND WTEXT, C L R DDKSHAD W, C L R INF TEXT x x , x , x Roșu închis x x , x , x Verde închis x x , x , x Galben închis x x , x , x Albastru închis x x , x , x Crimson închis x x , x , x Albastru închis x xC , xC , xC Gri deschis x xC , OxDC, OxCO x , x , x Money green C L R ACTIVECAPTI N, COLOR-HIGHLIGHT, COLOR-BTNSHADOW, COLORGRAYTEXT x OxAb, OxCA, OxFO xA , xC , xA Sky COLOR-MENU, C L R ACTIVEB RDER, COLOR-INACTIVEBORDER, COLOR-BTNFACE, C L R DLIGHT xF OxFF, OxFb, OxFO xD , OxEZ, xD Cremă C L R SCR LLBAR, COLOR-APPWORKSPACE, C L R INACTVECAPTI NTEXT, COLOR-BTNHIGHLIGHT Continuare Capitolul Tabelul Continuare Index RGB Valoare Nume Aplicație implicită xF x A, x E, xA x , x F, x xF x , x , x Gri închis xF OxFF, x , x Roșu OxFA x , OxFF, x Verde OxFB OxFF, OxFF, x Galben OxFC x , x , OxFF Albastru OxFD OxFF, x , OxFF Zmeura OxFE x , OxFF, OxFF Albastru OxFF OxFF, OxFF, OxFF Alb COLOR WINDOW, C L RCAPTI NTEXT, COLOR-HIGHLIGHTTEXT, COLORJNF BK Din cele de culori statice, culori închise sunt plasate în primele poziții ale paletei sistemului, iar culori deschise sunt plasate în ultimele poziții Aceste poziții sunt folosite pentru culorile „pure”: roșu, verde, albastru, magenta, galben, variantele lor închise și patru nuanțe de gri Când utilizați de culori statice, aceste sunt întotdeauna în aceleași locuri Acestea sunt plasate la capete diferite ale paletei pentru a înțelege operațiunile de bază bitmap dintre ele Este foarte important ca negrul să fie în poziția și alb în poziția , deoarece așa funcționează operațiunile bitmap cu masca Poziția este roșu închis (RGB( x , OxFF, x )); dacă indicele este inversat, acesta trece la OxFE, care corespunde culorii albastre (RGBCOxOO, OxFF, OxFF)) Nu se potrivește exact cu culoarea complementară de roșu închis din spațiul de culoare RGB (RGB( x F, OxFF, OxFF)), dar este suficient de aproape Combinarea roșului cu verdele produce galben pur deoarece xF | oxFA = oxFB Cele patru culori din mijlocul paletei se pot schimba în funcție de schema de culori selectată În tabel arată culorile lor RGB pentru două scheme de culori Aceste culori sunt utilizate pe scară largă în interfața cu utilizatorul Windows Ultima coloană a tabelului arată căror culori de sistem corespund în mod implicit În modul de culori, Windows încearcă întotdeauna să folosească culori statice ca culori de sistem Paleta logica Deși paleta de sistem conține de culori, dacă nu aveți grijă deosebită, aplicația dvs poate funcționa doar cu de culori statice sora Paleta logica paleta întunecată este o resursă la nivel de sistem, nu o resursă de context dispozitiv În contextele dispozitivelor, paleta de sistem corespunde paletelor logice Paleta logică controlează conversia culorilor utilizate în comenzile grafice GDI în indici de culoare framebuffer suprafeței grafice Paleta logică este unul dintre atributele contextului dispozitivului Paletele logice, cum ar fi pensulele logice, pixurile logice, fonturile logice și așa mai departe, formează o clasă separată de obiecte GDI Mai jos sunt descrieri ale structurilor de date și ale funcțiilor pentru lucrul cu paletele logice UINT GetPaletteEntries(HPALETE hpal, UINT iStartIndex UINT nEntries LPPALETTEENTRY Ippe); HPALETTE Create HalftonePalette(HDC hDC); HPALETTE SelectPalette (HDC hDC, HPALETTE hpal BOOL bForceBackground); UINT RealizePalette (HDC hDC): BOOL ResizePalette(HPALETT hpal, UINT nEntries); BOOL UnrealizeObject(HGDIOBJ hgdiObj); BOOL ResizePalette(HPALETTE hpal UINT nEntries); typedef struct tagLOGPALETTE { Versiune WORD pal; WORD palNumEntries; PALETTEENTRY palPalEntry[l]; } LOGPALETT; HPALETTE CreatePalette(CONST LOGPALETTE * Iplgpl); Paleta implicită Pentru a obține paleta logică asociată cu un context de dispozitiv, utilizați funcția GetCurrentObjectChDC, OBJ PAL) Un nou context implicit de dispozitiv i se atribuie paleta logică standard returnată de funcția GetStockObject(DEFAULT PALETTE) Paleta implicită conține exact de culori statice, prezentate în tabel , ; aceasta limitează numărul de culori disponibile pentru aplicație De exemplu, dacă utilizați macrocomandă PALETTEINDEX sau PALETTERGB pentru a defini o culoare într-un context de dispozitiv cu o paletă implicită, vor rămâne disponibile doar cele de culori statice ale tuturor culorilor solide Funcția WebColors de mai jos produce culori web Pe fig Figura arată rezultatul aplicării acestei funcții la paleta implicită În imaginea de sus, unde culorile sunt setate de macrocomenzi RGB, majoritatea elementelor sunt amestecate (cu excepția negru, roșu, verde, albastru, galben, cyan, magenta și alb, care sunt prezente în paleta sistemului) În figura de mai jos, care utilizează macrocomenzile PALETTERGB, este selectată cea mai bună potrivire pentru fiecare culoare din cele de culori din paletă În ambele cazuri, rezultatul este departe de a fi așteptat Capitolul mmnm shim ■■■■■■ mim ■■■piesă ■■■Nr IIIA ■YAM ■numele ■■ii ■YAMI ■IIH * mmmW^ x, ■■■■ cauciucuri ■iyaiya ■II» iaiii ■vize ■■■#*-SS ■IR ■ M#& shniya ■akya palVersion = x ; pLogPal->palNumEntries = : pentru (int i= ; i palPalEntry[i] = intrare; } HPALETTE hPal = CreatePalette(pLogPal); delete[] (BYTE *) pLogPal; return hpal; } O paletă logică cu indicatorul PC EXPLICIT este un caz destul de interesant Nu are scopul de a schimba paleta de sistem, ci de a permite culorilor paletei de sistem să fie folosite ca indici pentru paleta logică Când o paletă logică este selectată și implementată cu indicatorul PC EXPLICIT, culorile specificate de macro-ul PALETTEINDEX sunt asociate cu indecșii paletei de sistem specificați în structura LOGPALETE; chiar și macro-ul PALETTERGB funcționează ca PALETTEINDEX După crearea unei palete, puteți crește sau micșora numărul de culori din ea folosind funcția ResizePalette Când dimensiunea paletei este redusă, elementele eliminate nu pot fi folosite, dar elementele rămase rămân neschimbate Pe măsură ce dimensiunea paletei crește, elementele noi sunt umplute cu negru Funcția SetPal etteEntries este folosită pentru a inițializa elemente noi Capitolul Paleta Mesaje Când o fereastră implementează paleta logică principală, culorile non-statice sunt eliminate din paleta de sistem și culorile noi din paleta logică sunt scrise în locul lor Dacă fereastra unei aplicații care a folosit culorile non-statice ale paletei vechi de sistem rămâne pe ecran, imaginea din aceasta este grav distorsionată De exemplu, roșul se poate transforma în verde și verde în galben Pentru a se asigura că paleta de sistem poate fi utilizată în mod normal de mai multe ferestre simultan, Windows trimite mesaje către ferestrele de nivel superior informându-le despre modificările importante ale paletei WM QUERYNEWPALETTE În timp ce o fereastră este inactivă, alte ferestre pot modifica conținutul paletei de sistem, ducând la distorsiunea imaginii Când o fereastră este gata să primească focalizarea de la tastatură, Windows îi trimite un mesaj WM QUERYNEWPALETTE, astfel încât fereastra să-și poată restabili aspectul normal Dacă o fereastră folosește o paletă non-standard, trebuie să o implementeze ca paletă implicită și să redeseneze întreaga fereastră pentru a o restabili la aspectul optim Paleta folosită de aplicație trebuie creată în prealabil și stocată într-o variabilă de clasă fereastră sau variabilă globală Următoarea funcție arată cum este tratat mesajul WM QUERYNEWPALETTE LRESULT KWindow::OnQueryNewPalette(void) { if ( m hPalette==NULL ) returnează FALSE: HDC hDC = GetDC(m hWnd); HPALETTE h d= SelectPalette(hDC m hPalette FALSE): BOOL schimbat = RealizePalette(hDC) != : SelectPalette(hDC, Hold FALSE): ReleaseDC(m hWnd, hDC); daca (schimbat) { InvalidateRect(m hWnd, NULL TRUE): // Redesenează } returnare schimbată: } O nouă variabilă NULL, m hPalette, este adăugată la clasa noastră de ferestre de nivel superior, cu excepția cazului în care fereastra derivată dorește să folosească o paletă Când lucrați în modurile High Color și True Color și, de asemenea, în cazul în care sunteți limitat la culori statice, variabila m hPal ette rămâne egală cu NULL La primirea unui mesaj WM QUERYNEWPALETTE, funcția fereastră apelează Kwindow::OnQueryNewPalette sau o funcție suprascrisă Metoda OnQueryNewPalette creează un nou ghid de context al dispozitivului, selectează o paletă ca paletă de bază și o implementează Dacă implementarea paletei a avut succes (adică Paleta Mesaje că dispozitivul este paletat), zona client a ferestrei este invalidată, asigurându-se că este redesenată cu culorile corecte Funcția returnează TRUE dacă paleta a fost implementată și FALSE în caz contrar W SCHIMBARE DE PALETA Chiar înainte ca o aplicație să-și implementeze paleta logică, Windows trimite un mesaj WM PALETTEISCHANGING către ferestrele de nivel superior pentru a le informa cu privire la modificările iminente ale paletei de sistem Totuși, acest lucru nu înseamnă că implementarea paletei este întârziată în așteptarea confirmării Când fereastra activă implementează propria paletă, din cauza modificărilor din paleta sistemului, ferestrele din fundal pot fi grav distorsionate Mesajul WM PALETTEISCHANGING ar trebui să permită ferestrelor de fundal să se pregătească pentru modificări ale paletei de sistem De exemplu, o aplicație își poate șterge pur și simplu fereastra cu una dintre culorile statice, astfel încât imaginea să nu se schimbe atunci când paleta este modificată, apoi o redesenează din nou cu paleta de fundal aplicată Unul dintre articolele MSDN spune că mesajul WM PALETEISCHANGING este o arhitectură moștenită și ar trebui pur și simplu ignorat Experimentele au arătat că acest mesaj nu este trimis pe Windows Chiar și în pachetele profesionale, schimbarea paletei este însoțită de o distorsiune a culorii pe termen scurt WM PALETTECHANGED Schimbarea paletei sistemului poate fi însoțită de o distorsiune completă a culorilor în toate ferestrele, cu excepția celei active, astfel încât toate ferestrele suprapuse (suprapuse) și pop-up (roar) din sistem primesc un mesaj WM PALETTECHANGED Windows ar trebui să răspundă la acest mesaj și să încerce să-și restabilească imaginea cât mai mult posibil Parametrul wParam al mesajului WM PALETTECHANGED conține mânerul ferestrei care a schimbat paleta de sistem Fereastra care procesează acest mesaj ar trebui să verifice acest mâner pentru a se asigura că paleta nu a fost schimbată de la sine, ci de o altă fereastră, altfel nu trebuie făcut nimic Există două moduri de a restabili conținutul unei ferestre Prima modalitate, mai rapidă, este să implementați paleta logică ca paletă de fundal și să apelați funcția UpdateColors GDI pentru a îmbunătăți imaginea la nivel de pixel BOOL UpdateColors(hDC); Funcția UpdateColors iterează pe toți pixelii de pe suprafața dispozitivului și mapează indicii lor de culoare din paleta originală a sistemului la cei mai potriviti indici ai noii palete de sistem Probabil, în implementarea internă a UpdateColors, acesta construiește un tabel de mapare de la vechea paletă de sistem la cea nouă, apoi iterează peste pixeli și înlocuiește în funcție de tabel Capitolul Deoarece UpdateColors operează pe cadru tampon al dispozitivului, care conține o reprezentare aproximativă a imaginii, aplicarea UpdateColors de mai multe ori va duce la degradarea treptată a imaginii De exemplu, dacă desenul original a fost afișat color, atunci după ce aplicația trece la paleta în tonuri de gri, UpdateColors redă toți pixelii în tonuri de gri Dar când o altă fereastră implementează o paletă în tonuri de gri, funcția UpdateColors nu poate restabili corect o imagine color din tonuri de gri A doua modalitate de a gestiona mesajul WM PALETTECHANGED este să redesenați fereastra cu o implementare a paletei de fundal După cum am menționat mai sus, paleta de fundal nu elimină niciun element din paleta sistemului, ci încearcă doar să folosească elemente libere și să-și potrivească culorile logice la setul existent Dacă noua paletă de sistem este bine echilibrată, puteți obține o calitate destul de decentă Mai jos este un exemplu de handler de mesaje WM PALETTECHANGED Verificăm dacă paleta a fost schimbată de fereastra curentă comparând mânerul ferestrei cu wParam Dacă mânerele nu se potrivesc și fereastra folosește o paletă, acea paletă este selectată și implementată Programul numără de câte ori a fost apelată funcția UpdateColors Cu o valoare mică a contorului se apelează funcția UpdateColors, care oferă o actualizare accelerată; în caz contrar, fereastra este redesenată pentru a îmbunătăți calitatea imaginii LRESULT KWwindow::OnPa etteChanged(HWND hWnd WPARAM wParam) { if ( ( hWnd != (HWND) wParam ) && m hPalette ) { HDC hDC = GetDC(hWnd); HPALETTE hold = SelectPalette(hDC m hPalette, FALSE); dacă (RealizePalette(hDC)) if ( m nUpdateCount >= ) { InvalidateRect(hWnd NULL, TRUE); m nUpdateCoint = ; } altfel { UpdateColors(hDC); m nUpdateCount++; } SelectPalette(hDC, Hold, FALSE); ReleaseDC(hWnd, hDC); } returnează : } Programul de testare Să punem totul împreună într-o clasă de ferestre mici pentru ieșirea DIB folosind o paletă în tonuri de gri Se afișează clasa KDIBWindow Paleta Mesaje cum să creați o paletă logică, să o implementați și să o utilizați pentru a afișa un raster și cum să gestionați mesajele paletei folosind funcțiile descrise mai sus Lista - arată codul complet pentru clasa de ferestre DIB derivată din KWindow Metoda CreateDIBWindow, care preia un bitmap DIB despachetat printre alți parametri, creează o fereastră temporară Opțiunea de opțiune vă permite să comparați modul în care programul funcționează cu și fără paletă, atunci când procesați mesaje din paletă și când bliting cu scalare Managerul de mesaje WM CREATE creează o paletă în tonuri de gri dacă este specificat de valoarea parametrului opțiune Managerul WM PAINT folosește o paletă pentru a afișa un raster Managerul WM PALETTECHANGED restabilește imaginea coruptă, ghidată și de valoarea parametrului opțiune Managerul WM QUERYNEWPALETTE implementează o paletă în tonuri de gri Paleta creată este distrusă în handlerul de mesaje WM NCDESTROY Lista , Ieșire raster bazată pe paletă typedef enumerare pal no = x , pal halftone = x pal bitmap = x // Fără paletă // Folosește paleta de semitonuri // Folosește paleta DIB/DIB secțiune pal react = x , // Reacționează la mesajul WM PALETTECHANGED pal stretchHT= x // Utilizați modul STRETCH HALFTONE HPALETTE CreateDIBSectionPalettetHDC hDC, HBITMAP hDIBSec); clasa KDIBWindow ■ KWIndow publică const BITMAPINFO * m pBMI; const BYTE * m pBits; int m nOpt on; virtual LRESULT WndProcCHWND hWnd UINT uMsg WPARAM wParam LPARAMIParam) { comutator(uMsg) { caz WM CREATE: m hWnd = hWnd; { HDC hDC = GetDC(m hWnd); if ( (m nOption & )==pal-bitmap ) ffl-hPalette = CreateDIBPalette(m pBMI); else if ( (mjiOption & )==pal halftone ) m hPalette = CreateHalftonePalette(hDC); altfel m hPalette = NULL; ReleaseDC(m hWnd hDC): } returnează : Continuare Capitolul Lista Continuare caz WM-PAINT: { PAINTSTRUCT ps; HDC hDC = BeginPaint(hWnd & ps); HPALETTE hold = SelectPalette(hDC, m hPalette, FALSE); RealizePalette(hDC); if ( m nOption & pal stretchHT ) { SetStretchBltMode(hDC, STRETCH HALFTONE); } altfel SetStretchBltMode(hDC, STRETCH DELETESCANS); StretchDIBits(hDC, , , m pBMI->bmi Header biWi dth, m pBMI->bmi Header bi Hei ght, , m pBMI->bmiHeader biWidth, m pBMI->bmi Header bi Hei ght,, m pBMI, DIB RGB COLORS, SRCCOPY); EndPaint(hWnd, &ps); } întoarce ; caz WM PALETTECHANGED: if ( mjiOption & pal react ) return OnPaletteChanged(hWnd, wParam); pauză; caz WM QUERYNEWPALETTE: return OnQueryNewPalette(); caz WMJOESTROY: DeleteObject(m hPalette); m hPalette = NULL; întoarce ; } returnează DefWindowProc(hWnd, uMsg, wParam, IParam); public: void CreateDIBWindow(HINSTANCE hlnst, const BITMAPINFO * pBMI, const BYTE * pBits, opțiune int) { if ( pBMI==NULL ) return; opțiunea mjiOption"; m pBMI = pBMI; m pBits = pBits; Paleta Mesaje TCHAR t tle[ ]; wsprintf(titlu, T ("DIB Wlndow (£d)"), m n pt on); CreateEx(O, T("DIBW ndow"), titlu, WSJJVERLAPPEDWINDOW | WS CLIPCHILDREN, CWJJSEDEFAULT, CWJJSEDEFAULT, m pBMI->bm Header blWidth + m pBMI->bm ULLHader + NULL,N ,bl); ShowW ndow(SW NORMAL); updatewindowo; } }; Pe fig prezintă două versiuni ale imaginii În fereastra din stânga, imaginea a fost obținută fără a utiliza paleta semiton (opțiune = pal no) Pixelii de culoare ai imaginii sunt înlocuiți cu de culori statice, astfel încât imaginea este gri și plictisitoare În fereastra din dreapta a fost folosită o paletă semiton (opțiune = pal semiton); desenul a devenit foarte colorat, cu tranziții netede de culoare Deși culorile nu diferă pe paginile cărții, chiar și tonurile de gri pot fi judecate în funcție de calitatea imaginii Orez Ieșire DIB cu și fără tonuri de gri Figura ilustrează consecințele manipulării mesajelor din paletă Fereastra din stânga (opțiune = pal halftone) ignoră mesajul WM PALETTECHANGED, pierzând șansa de a restabili imaginea atunci când paleta sistemului este modificată Fereastra din dreapta (option = pal halftone| pal react) actualizează culorile sau redesenează imaginea cu paleta de fundal Probabil că nu este nevoie de comentariu Pe ecran, unele diferențe sunt evidente datorită diferențelor dintre fundal și paletele principale, deși pe hârtie desenele arată din nou aproape la fel Dacă fereastra de nivel superior are ferestre copil (în special în aplicațiile MDI), trebuie să gestionați corect redirecționarea mesajelor din paletă, deoarece fără aceasta mesajele nu vor ajunge în ferestrele secundare Capitolul Orez Ieșire DIB fără procesare WM PALETTECHANGED Mesajul WM QUERYNEWPALETTE este trimis doar la o fereastră de nivel superior atunci când primește focus Fereastra principală MDI trebuie să trimită acest mesaj către fereastra secundară MDI activă Dacă ferestrele copil MDI folosesc palete diferite, orice fereastră copil trebuie să poată implementa paleta sa ca paletă principală atunci când primește focus Mesajul WM PALETTECHANGED este de asemenea trimis numai către ferestrele de nivel superior Fereastra MDI principală trebuie să o redirecționeze către toate ferestrele sale secundare, astfel încât toate să aibă șansa de a răspunde la modificările aduse paletei de sistem Paletă și rastere În comparație cu grafica vectorială care utilizează pixuri și pensule, graficele raster cauzează mai multe probleme în modurile video cu palete De exemplu, simpla încărcare a unui bitmap cu funcția LoadBitmap nu mai este potrivită, deoarece o imagine care poate conține mii de culori va fi aproximată cu câteva culori statice Dacă bitmap-ul conține un tabel de culori, acesta ar trebui convertit într-o paletă logică Windows și utilizat corect pentru cele mai bune rezultate La afișarea rasterelor High Color și True Color în modul de de culori, un rezultat acceptabil este obținut numai prin construirea unei palete optime și a unei procesări de semitonuri a imaginii în conformitate cu conținutul paletei Această secțiune discută problemele obișnuite care apar la afișarea bitmaps-urilor în moduri video cu palete Paletă și rastere Rastere și palete dependente de dispozitiv Cel mai simplu mod de a converti un bitmap BMP într-un bitmap DDB este să utilizați funcția LoadBitmap sau Loadlmage Funcția LoadBitmap convertește un fișier BMP atașat la un EXE/DLL ca resursă într-un DDB Funcția Loadlmage convertește fie o resursă bitmap, fie un fișier BMP extern în DDB, deși Loadlmage vă permite și să încărcați o imagine într-o secțiune DIB Nici contextul dispozitivului, nici paleta logică nu sunt trecute printre parametrii acestor funcții La construirea DDB, funcțiile LoadBitmap și Loadlmage folosesc doar de culori statice Toți pixelii de culoare din raster sunt înlocuiți cu cea mai apropiată culoare potrivită din acest set mic Un exemplu este prezentat în fig , rămase Pentru a construi un raster DDB multicolor, aveți nevoie de o paletă logică care controlează conversia culorilor din DIB în DDB Paleta poate fi în tonuri de gri, personalizată sau generată din paleta de sistem Lista arată noua funcție de încărcare raster paletizat Lista - Încărcarea unui raster DDB cu suport pentru paletă BYTE static * GetDIBPixelArray(BITMAPINFO * pDIB) { return (BYTE *) & pDIB->bmiColors[GetDIBColorCount(pDIB->bmiHeader)J; } // Creați o paletă booleană care să conțină toate culorile // paleta curentă a sistemului HPALETTE CreateSystemPalette(void) { LOGPALETTE * pLogPal = (LOGPALETTE *) new charEsizeof(LOGPALETTE) + dimensiunea(PALETTENTRY) * ]: pLogPal->palVersion = x ; pLogPal->palNumEntries s : HDC hDC » GetDC(NULL); GetSystemPaletteEntries(hDC pLogPal->palPalEntry); ReleaseDC(NULL hDC); HPALETTE hPal = CreatePalette(pLogPal); delete[] (char*) pLogPal; return hpal; } // Încărcați DIB din resursă sau fișier BITMAPINFO * LoadDIB(HINSTANCE hlnst, LPCTSTR pBitmapName bool & bNeedFree) { HRSRC hRes = FindResource(hInst, pBitmapName RT BITMAP); BITMAPINFO*pDIB; Continuare Capitolul Lista - Continuare dacă (hRes) { HGLOBAL hGlobal - LoadResource(hInst hRes): pDIB - (BITMAPINFO *) LockResource(hGlobal): bNeedFree - false: ) altfel { HANDLE handle = CreateFile(pBitmapName GENERIC READ FILE SHARE READ, NULL OPENJXI STING, FILE ATTRIBUTE NORMAL, NULL); if ( handle " INVALID HANDLE VALUE ) returnează NULL: BITMAPFILEHEADER bmFH: DWORD dwRead = ; ReadFile(handle & bmFH sizeof(bmFH) & dwRead, NULL): if ( (bmFH bfType == x D ) && (bmFH bfSize bmiHeader biWidth: int inaltime = pDIB->bmiHeader biHeight; HDC hMemDC * CreateCompatibleDC(NULL): HBITMAP hBmp = CreateBitmap(lățime, înălțime, GetDeviceCaps(hMemDC PLANES), GetDeviceCaps(hMemDC BITSPIXEL), NULL): HGDIOBJ hOldBmp » SelectObject(hMemDC, hBmp): Paletă și rastere HPALETTE hold = SelectPalette(hMemDC, hPalette, FALSE); Rea zePa ette(hMemDC); SetStretchBltMode(hMemDC, HALFTON); StretchDIBits(hMemDC , , lățime, înălțime, , , lățime înălțime, GetDIBPixelArray(pDIB), pDIB, DIB RGB COLORS, SRCCOPY); SelectPalette(hMemDC, Hold, FALSE): SelectObject(hMemDC, hOldBmp); DeleteObject(hMemDC): dacă (bDIBNeedFree) șterge[] (BYTE *) pDIB; return hBmp; } În comparație cu LoadBitmap , funcția PaletteLoadBitmap preia un parametru suplimentar, un manipulator de paletă logic Paleta logică este selectată într-un context de dispozitiv compatibil înainte de a converti bitmap-ul DIB încărcat în DDB, astfel încât bitmap-ul DDB generat poate folosi toate culorile din paleta logică Funcția LoadDIB încarcă un bitmap dintr-o resursă sau un fișier extern ca bitmap DIB împachetat Funcția de ajutor CreateSystemPalette creează o paletă logică care conține toate culorile din paleta curentă a sistemului Manipulatorul transmis la PaletteLoadBi tmap trebuie să se potrivească cu paleta logică utilizată la redarea bitmap-ului De exemplu, dacă aplicația este un program de joc care funcționează cu o paletă în tonuri de gri, atunci hărțile de biți din joc trebuie să fie încărcate cu o paletă în tonuri de gri Fereastra principală a programului trebuie să proceseze mesajele din paletă pentru a se asigura că este selectată o paletă de semitonuri la ieșirea bitmap-urilor Rasterele DDB sunt utilizate pe scară largă pentru afișarea graficelor pe bare de instrumente, butoane, controale, meniuri etc De obicei, afișajul este sub controlul sistemului de operare, deși este posibilă și o opțiune desenată de proprietar Sistemul de operare folosește paleta implicită atunci când afișează DDB, așa că dacă o aplicație dorește să folosească mai mult de de culori statice, culorile bitmap trebuie să se potrivească cu conținutul paletei curente de sistem Cu alte cuvinte, de fiecare dată când schimbați paleta de sistem, aceste rastere trebuie să fie restaurate din nou Mai jos este o funcție pentru afișarea unei bare de instrumente cu mai mult de de culori Este implementat în clasa KToolbarB, care este derivată din clasa KToolbarB Funcția KToolbar::SetBitmap trebuie apelată ori de câte ori paleta de sistem este schimbată Încarcă bitmap-ul utilizând paleta curentă a sistemului și folosește mesajul TB REPLACEBITMAP pentru a înlocui bitmap-ul curent al barei de instrumente Acum puteți folosi mai multe culori în barele de instrumente în modul de culori BOOL KToolbarB::SetBitmap(HINSTANCE hlnstance, int resourceID) { HPALETTE hPal » CreateSystemPaletteO: Capitolul HBITMAP hBmp = PaletteLoadBitmap(hlnstance MAKEINTRESOURCE(ID resursă), hPal); DeleteObject(hpal): dacă (hBmp) TBREPLACEBITMAP rp: rp hlnstOld = m ResInstance: rp nIDOld = m ResId: rp hlnstNew = NULL; rp nIDNew = (UINT) hBmp; rp nButoane = ; SendMessage(m hWnd, TB REPLACEBITMAP, , (LPARAM) & rp); if ( m ResInstance==NULL ) DeleteObject( (HBITMAP) m ResId): m ResInstance = NULL; m ResId = (UINT) hBmp; returnează TRUE; } altfel returnează FALSE; } Rastere și palete independente de dispozitiv Spre deosebire de hărțile de biți dependente de dispozitiv, fiecare bitmap independent de dispozitiv (DIB) conține informații complete color, permițându-i să fie afișat pe orice dispozitiv În modurile High Color și True Color, fiecare pixel conține date complete de culoare; în alte moduri, indicii sunt mapați la valori RGB dintr-un tabel de culori Principala problemă cu ieșirea DIB pe sistemele cu palete este alegerea paletei pe care să o utilizați la afișarea bitmap-ului Ieșirea DIB cu paleta implicită permite doar de culori statice Paleta de semitonuri este potrivită pentru afișarea graficelor de afaceri cu culori bogate și distribuite uniform Pentru hărțile de biți cu distribuție neuniformă a culorilor în spațiul RGB, o paletă specializată este mai potrivită decât paletele de uz general (cum ar fi paleta în tonuri de gri) Dacă numărul de culori dintr-un raster nu depășește , tabelul de culori raster este ușor convertit într-o paletă logică Pentru bitmapurile High Color sau True Color, Windows vă permite să specificați un tabel de culori pentru ieșire pe dispozitivele cu o paletă (deși cu greu vă puteți aminti cel puțin o aplicație care ar folosi această caracteristică) Lista arată o funcție pentru a construi o paletă logică bazată pe tabelul de culori DIB Paletă și rastere Lista Convertiți culorile DIB în paletă booleană HPALETTE CreateDIBPalette(const BITMAPINFO * pDIB) { BYTE*pRGB: intnSize; int Culoare; dacă (pDIB->bmiHeader biSize==sizeof(BITMAPCOREHEADER)) // OS/ { pRGB = (const BYTE *) pDIB + sizeof(BITMAPCOREHEADER); nSize = sizeof(RGBTRIPLE); nColor = "((BITMAPCOREHEADER *) pDIB)->bcBitCount; altfel { ncolor = ; dacă (pDIB->bmiHeader biBitCount bmiHeader biBitCount; if ( pDIB->bmiHeader biClrUsed ) nColor = pDIB->bmiHeader biCIrUsed; dacă ( pDIB->bmiHeader biClrImportant ) nColor - pDIB->bmiHeader biCirImportant; pRGB = (BYTE *) & pDIB->bmiColors; nSize = sizeof(RGBQUAD); dacă ( pDIB->bmiHeader biCompression==BI BITFIELDS ) pRGB += * dimensiunea(RGBQUAD); } dacă (nColor> ) ncolor = ; dacă (nColor== ) returnează NULL; LOGPALETTE * pLogPal » (LOGPALETTE *) nou BYTE[sizeof(LOGPALETTE) + sizeof(PALETTENTRY) * (nColor- )]; HPALETTE hPal; dacă (pLogPal) { pLogPal->palVersion » x ; pLogPal->palNumEntries - nColor; pentru (int i= ; i palPalEntry[i] peBlue - pRGB[ ]; pLogPal->palPalEntry[i] peGreen - pRGB[l]; pLogPal->palPalEntry[i] peRed = pRGB[ ]; pLogPal->palPalEntryti] peFlags » ; Continuare^ Capitolul Lista Continuare pRGB += nDimensiune: hPal = CreatePalettetpLogPal): } delete[] (BYTE *) pLogPal; return hpal: } Orez Ieșire DIB cu paletă semiton, cu paletă semiton în modul HALFTON și cu paletă personalizată Paletă și rastere Funcția caută în DIB un tabel de culori și determină numărul de culori necesare pentru afișarea bitmap-ului Având în vedere că numai de culori non-statice pot fi realizate în circumstanțe normale, nu este recomandat să folosiți mai mult de de culori non-statice în tabelul de culori DIB Câmpul bi Cir Important este furnizat special pentru a reduce numărul de culori necesare Este recomandabil să sortați culorile din tabel după frecvența de utilizare Dacă unele dintre ele nu sunt incluse în paletă, excluderea ar trebui să înceapă cu cele mai puțin utilizate culori Funcția CreateDIBPalette folosește tabelul de culori DIB numai pentru a construi o paletă logică Problema construirii unei palete optime pentru imagini High Color și True Color este discutată în secțiunea următoare pe un subiect mai general - reducerea numărului de culori într-un raster Între timp, dacă DIB-ul nu conține un tabel de culori, programul nostru va folosi o paletă în tonuri de gri Efectul umplerii paletei cu date din tabelul de culori DIB poate fi foarte vizibil Aruncă o privire la fig , ; prima imagine este redată cu o paletă în tonuri de gri fără modul de scalare în tonuri de gri (vezi capitolul ) A doua imagine a fost scoasă cu o paletă în tonuri de gri și scalare în tonuri de gri; Calitatea desenului s-a îmbunătățit considerabil Ultimul desen a fost obtinut folosind o paleta specializata bazata pe tabelul de culori, fara scalare de semitonuri S-ar putea să vă surprindă că atunci când utilizați o paletă bazată pe un tabel de culori, modul de scalare în tonuri de gri nu îmbunătățește deloc calitatea imaginii Rezultatul este aproape același ca atunci când utilizați o paletă de semitonuri cu scalarea semitonurilor activată Indexul paletei în tabelul de culori DIB Când redați un DIB, funcții cum ar fi StretchDIBits trec de obicei indicatorul DIB RGB COLORS Acest indicator îi spune GDI că tabelul de culori DIB conține valori RGB GDI asociază valorile RGB din tabelul de culori cu culorile din paleta logică și apoi convertește indecșii paletei logice în indecșii paletei de sistem care sunt scrise în framebuffer Căutarea culorilor potrivite în paletă este destul de lentă GDI oferă două caracteristici care permit aplicațiilor să aleagă singure culorile: UINT GetNearestPaletteIndex(HPALETTE hPal, COLORREF crColor): COLORREF GetNearestColor(HDC hDC COLORREF crColor): Funcția GetNearestPaletteIndex scanează prin toate culorile din paleta logică, căutând cea mai apropiată potrivire pentru o referință dată Proximitatea este definită ca distanța dintre două culori în spațiul de culoare RGB Pentru două culori RGB(rl,gl,bl) și RGB(r ,g ,b ) distanța este calculată prin formula V(g -g ) + (gl-g ) + (M-b ) Capitolul În scopul găsirii celei mai apropiate potriviri, GDI poate folosi pur și simplu pătratul distanței pentru a evita calculul lent al rădăcinii pătrate Funcția GetNearestColor găsește cea mai apropiată culoare din paleta de sistem pentru referința dată și o returnează Desigur, GDI nu se potrivește culorilor pentru fiecare pixel La ieșirea unui DIB cu indicatorul DIB RGB COLORS, GDI preia înlocuitori pentru toate culorile din tabelul de culori și folosește rezultatul pentru a scoate toți pixelii din raster Dacă paleta logică curentă se bazează pe un tabel de culori bitmap, GDI vă permite să săriți peste primul pas al căutării Pentru a profita de această optimizare, aplicația trebuie să înlocuiască valorile RGB din tabelul de culori DIB cu indici de paletă logică și apoi să treacă steag-ul DIB PAL COLORS în loc de DIB RGB COLORS atunci când se utilizează DIB Cu indicatorul DIB PAL COLORS, tabelul de culori DIB este interpretat ca o matrice de indici de paletă logică Următoarea funcție creează o structură BITMAPINFO cu un tabel de culori care conține indici de paletă BITMAPINFO * IndexColorTable(BITMAPINFO * pDIB, HPALETTE hPal) { intnSize: int Culoare; const BYTE * pRGB = GetColorTable(pDIB, nSize, nColor): if ( pDIB->bmiHeader biBltCount> )// Nicio modificare returnează pDIB: // Creați o nouă structură BITMAPINFO pentru modificare BITMAPINFO * pNew = (BITMAPINFO *) new BYTEEsizeof(BITMAPINFOHEADER) +dimensiunea(RGBQUAD)*nColor]: pNou->bmiHeader = pDIB->bmiHeader: WORD * plndex = (WORD *) pNew->bmiColors; pentru (int i= : i RemoveAll O; Ghildei] = NULL: } șterge asta: int KNode::PickLeaves(RGBQUAD * pEntry, Int * pFreq, int size) dacă (dimensiune== ) întoarce ; Dacă(EsteLeaf) { *pFreq=Pixeli: pEntry->rgbRed = ( SigmaRed + P xels/ ) / Pixeli: pEntry->rgbGreen = ( SigmaGreen + P xels/ ) / Pixeli: pEntry->rgbBlue = ( SigmaBlue + Pixeli/ ) / Pixeli: pEntry->rgbReserved = : întoarcere : } altfel { Sumă int = : for (Int = : P ckLeaves(pEntry+sum, pFreq+sum, slze-sum); suma returnată; } } Variabila IsLeaf indică dacă nodul este un nod frunză Un nod frunză este definit ca un nod care nu are copii În starea inițială a arborelui, toate nodurile frunzelor se află la al nouălea nivel În procesul de fuziune, nodurile de nivel superior pot deveni și noduri frunză Matricea Child conține pointeri către cei copii ai unui nod care nu este frunză În alte variabile Cuantificarea culorilor stochează numărul de pixeli și suma componentelor lor RGB pentru toți pixelii din subarborele a cărui rădăcină este nodul curent De exemplu, variabila Pixeli a nodului rădăcină conține numărul total de pixeli din întregul arbore Rețineți că suma este stocată într-un număr întreg fără semn de de biți, astfel încât arborele octanți nu poate stoca mai mult de de pixeli Constructorul clasei KNode este foarte simplu - se limitează la inițializarea variabilelor clasei Metoda RemoveAl elimină toate nodurile subarborelui curent folosind recursiunea normală Metoda PickLeaves colectează informațiile rezumative acumulate în arbore Umple o matrice de structuri PALETTEENTRY cu valori RGB și populează o matrice întregă cu informații despre distribuția culorilor Pentru a face acest lucru, pur și simplu iterăm peste nodurile arborelui și convertim fiecare nod frunză într-o structură PALETTEENTRY a cărei valoare RGB este calculată prin media valorilor RGB ale tuturor pixelilor Numărul de pixeli reprezentați de fiecare nod este, de asemenea, stocat în matricea de frecvențe Această valoare opțională poate fi folosită pentru a sorta matricea PALETTEENTRY după frecvența culorii Clasa arborelui octanți KOctree este prezentată în Lista Lista Clasa arborelui octant folosit pentru cuantificarea culorilor clasa KOctree { typedef enumerare { MAXMODE = }; KNode*pRoot; int TotalNode; int TotalLeaf: void Reduce(KNode * pTree, prag nesemnat): public: KOctreeO { pRoot = KNode nou (fals): TotalNode = : TotalLeaf = ; } -KOctree" { dacă (proRoot) { pRoot->RemoveAl : pRoot = NULL: } } void AddColor(BYTE r BYTE g BYTE b): void ReduceLeaves(int limit): int GenPalette(RGBQUAD *intrare int * Frecvență, dimensiune int): Continuare Capitolul Lista Continuare void Merge(KNode * pNode, KNode și țintă); void KOctree::AddColor (BYTE r BYTE g BYTE b) { KNode * pNode = pRoot; pentru (BYTE mask= x : mask!=O: mask"=l) // Mergeți la nodul frunză { // Adăugați un pixel pNode->Pixeli ++: pNode->SigmaRed += r; pNode->SigmaGreen += g; pNode->SigmaBlue += b: dacă (pNode->IsLeaf) pauză: // Luați câte un bit din fiecare componentă // pentru a forma un index int index = ( (z & mask) ? : O ) + ((g & mască) ? :O) + ((b & mască) ? : O ): // Creați un nou nod dacă este o ramură nouă if ( pNode->ChildCindex]==NULL ) { pNode->Chi d[index] = nou KNode(masca== ): TotalNode++: if ( masca== ) TotalLeaf++: } // Urmăriți în continuare pNode = pNode->Copil[index]: } pentru (int threshold=l: TotalNode>MAXMODE; threshold++ ) Reduce(pRoot, threshold): } // Îmbină nodul cu nodurile frunză copil // și numărul de pixeli care nu depășește pragul // Îmbină nodul frunză cu numărul de pixeli // care nu depășește pragul, cu cel mai apropiat vecin void KOctree::Reduce(KNode * pTree, prag nesemnat) { if ( pTree==NULL ) întoarcere: bool childallleaf = adevărat: Cuantificarea culorilor // Apel recursiv la toți copiii care nu sunt frunze pentru (int = : Ch d[ ] && ! pTree->Chi d[ ]->IsLeaf ) Reduce (pTree->Ch d[ ], prag): if ( ! pTree->Chi d[ ]->IsLeaf ) childallleaf = false: } // Dacă toți copiii sunt noduri de frunze, // iar numărul de pixeli nu depășește pragul - merge if ( childallleaf & (pTree->P xels Ch ld[ ] ) { șterge pTree->Ch d[ ]: pTree->Ch d[ ] = NULL: TotalNode TotalLeaf pTree->IsLeaf = adevărat: TotalLeaf++: întoarcere: } // Îmbina copiii frunzelor // cu câțiva pixeli pentru ( = : Ch ld[ ] && pTree->Ch d[ ]->IsLeaf && (pTree->Ch d[ ]->P xels Ch d[ ]: șterge pTree->Ch d[ ]: pTree->Ch d[ ] = NULL: TotalNode TotalLeaf pentru (Int j= : j Ch ld[j] ) { Merge(pTree->Ch d[jL temp): break: } } } vold KOctree::Merge(KNode * pNode, KNode și țintă) { în timp ce (adevărat) Continuare Capitolul Lista Continuare pNode->Pixeli += target Pixeli: pNode->Si gmaRed += target Si gmaRed: pNode->SigmaGreen += target SigmaGreen: pNode->Si gmaBlue += target Si gmaBlue: dacă (pNode->IsLeaf) pauză: KNode * pChild = NULL: pentru (int i= ; i Copil[i] ) { pChild = pNode->Child[i]: break: } if ( pChild==NULL ) { afirmă (FALSE): întoarcere: } altfel pNode = pChild: } } void KOctree::ReduceLeaves(int Urnit) { pentru (prag nesemnat=l: TotalLeaf>limit: threshold++) Reduce(pRoot, threshold): int KOctree::GenPalette (intrare RGBQUAD[], int * pFreq, dimensiune int) { ReduceLeaves(dimensiune): returnează pRoot->PickLeaves(intrare, pFreq, dimensiune): } Variabilele clasei KOctree sunt destul de simple Variabila pRoot se referă la nodul rădăcină, de la care legăturile duc la toate celelalte noduri Numărul total de noduri și noduri de frunze din arbore este stocat în variabilele Total Node și Total Leaf În starea inițială, arborele constă din nodul rădăcină creat în constructor Ștergerea tuturor nodurilor se face în destructor Metoda AddColor face cea mai mare parte a lucrărilor de construire a arborelui Obține componentele roșii, verzi și albastre ale unui pixel în spațiul RGB Culoarea este adăugată mai întâi la nodul rădăcină, după care indexul nodului de nivel al doilea este format din primii biți ai componentelor RGB Pixelul este adăugat la toate nivelurile până când întâlnim un nod frunză Dacă în timpul iterației se dovedește că subnodul nu a fost încă creat, metoda îl creează Obra Cuantificarea culorilor Rețineți că nodurile frunze îmbinate nu sunt re-divizate Numărul maxim de noduri din clasa KOctree este stabilit de constanta MAXNODE Această constantă este în prezent ; acest lucru este de obicei suficient pentru a reprezenta cu acuratețe imagini pe biți Arborele maxim permis necesită aproximativ MB de memorie Dacă arborele conține prea multe noduri, AddColor apelează metoda Reduce pentru a face reducerea Reducerea se realizează prin creșterea treptată a pragului, a cărui valoare inițială este În prima trecere, toate nodurile frunzelor care conțin un pixel sunt îmbinate Dacă mai sunt prea multe noduri după prima trecere, pragul este crescut și procesul se repetă Metoda Reduce implementează algoritmul de reducere în trei pași În primul rând, toate subnodurile care nu sunt frunze sunt reduse printr-un apel recursiv la Reduce Dacă după aceea toate subnodurile nodului curent sunt noduri frunză și numărul total de pixeli nu depășește pragul, toate subnodurile sunt eliminate și nodul curent este marcat ca nod frunză Amintiți-vă ce s-a spus mai sus: AddColor adaugă informații la fiecare nivel al arborelui, astfel încât fiecare nod conține un rezumat al tuturor subnodurilor sale În pasul final, Reduce verifică toate subnodurile frunzelor cu un număr mic de pixeli și le îmbină cu unul dintre nodurile învecinate Îmbinarea nodurilor învecinate se realizează prin metoda Merge Metoda găsește pur și simplu ramura către nodul frunză și include datele RGB în ea Un algoritm mai rațional ar trebui să ofere o căutare pentru cea mai apropiată potrivire Funcțiile de mai sus construiesc arborele și efectuează trunchierea necesară dacă arborele devine prea mare După ce arborele este construit, metoda ReduceLeaves îl reduce treptat până când numărul de noduri frunze este sub limita permisă Pentru a reduce un copac cu un prag în creștere, este folosită metoda deja familiară Reduce Nodurile mici se îmbină treptat în noduri mai mari de un nivel superior, iar nodurile mari nu participă la îmbinare până când pragul este ridicat la o valoare suficient de mare Ideea este ca un număr limitat de noduri frunze să reprezinte cât mai aproape posibil distribuția culorilor în imagine Astfel, nodurile cu un număr mare de pixeli sunt mai probabil să se afle în setul final de culori decât nodurile cu un număr mic de pixeli Metoda GetPal ette completează cuantificarea populând o matrice de structuri PALETTEENTRY și o matrice de frecvențe Apelează metoda ReduceLeaves pentru a reduce numărul de noduri frunze la valoarea specificată, iar metoda KNode: :PickLeaves pentru a popula cele două tablouri Trebuie doar să trecem toți pixelii raster-ului la clasa KOctree pentru a construi un arbore și apoi să generăm o paletă din datele nodurilor frunzelor Clasa KPaletteGen este prezentată în Lista - Lista Clasa KPaletteGen: construirea unei palete folosind lemn octant clasa KPaletteGen : KPixelMapper public Capitolul KOctree octree: // Returnează adevărat dacă datele s-au schimbat virtual bool MapRGB (BYTE și roșu, BYTE și verde BYTE și albastru) { octree AddColor(rosu, verde, albastru); returnează fals; } public: void AddB tmap(KImage & dib) { dib PixelTransform(* this): } int GetPalette(RGBQUAD * pEntry int * pFreq int size) { return octree GenPalettetpEntry, pFreq mărimea); } }: int GenPaletteBITMAPINFO *pDIB RGBQUAD *pIntrare int * pFreq dimensiune int) { Klmage dib; KPaletteGen pal gen; d b AttachDIB(pDIB, NULL, ); palgen AddBltmap(dlb); return pal gen GetPalette(pEntry, pFreq size): } Clasa KPaletteGen derivă din clasa KPixelMapper creată în Capitolul pentru a transforma pixelii DIB Probabil nu ați uitat că clasa KPixelMapper trebuie doar să implementeze metoda MapRGB, care va fi apelată pentru fiecare pixel din raster Metoda KPaletteGen::MapRGB adaugă pur și simplu un pixel de culoare la o instanță a clasei KOctree Metoda AddBitmap iterează peste toți pixelii dintr-un raster și apelează MapRGB pentru fiecare pixel Metoda GetPalette returnează tabelul final de culori Funcția globală GenPalette generează un tabel de culori pentru un raster DIB împachetat, pentru care utilizează clasele Klmage și KPaletteGen Paleta generată de algoritmul de cuantizare a arborelui octanți oferă o calitate foarte bună chiar și în comparație cu pachetele grafice profesionale Mai jos este un tabel de culori cu culori construit pentru imaginea tigrului din fig Pentru fiecare element din tabelul de culori, sunt enumerate valorile RGB și numărul de pixeli reprezentați de element După cum puteți vedea, numărul de pixeli reprezentați este bine echilibrat Cuantificarea culorilor PALETTEENTRY Pa [] = // Pentru imaginea tigrului din fig , , , DIN DIN , , , , } // } // } // } // } // } // } // PE } // } // } // } // } // }, // } // } // } // , , , , , , , , I , , , Pe fig Figura prezintă o imagine a unui tigru cu palete de , și de culori generate de algoritmul de cuantificare a arborelui octanți fără semitonuri Algoritmul de cuantificare a arborelui octanți este folosit și în alte scopuri Editorii grafici oferă adesea capacitatea de a număra culorile într-un raster pentru a selecta o metodă de compresie Pentru imaginile True Color, numărarea numărului exact de culori nu este o sarcină ușoară, deoarece există , milioane de variante posibile Un arbore octant este o structură de date convenabilă pentru această sarcină Numărul de culori din imagine este același cu numărul de noduri frunze din vizualizarea arborescentă, atâta timp cât avem suficientă memorie pentru a scana complet imaginea Dacă clasa KNode este folosită doar pentru numărarea culorilor, poate fi optimizată pentru a reduce supraîncărcarea memoriei O modalitate alternativă de numărare a culorilor este construirea unei matrice de x x biți în care fiecare bit reprezintă o culoare în spațiul RGB de x x Costul total al unei celule este de MB Capitolul Reducerea adâncimii de culoare a unui raster Deci, avem un algoritm bun pentru construirea unei palete „optimale” Următorul pas este să convertiți rasterele High Color și True Color într-un raster index sau să reduceți cu totul adâncimea de culoare a rasterului De exemplu, putem converti un raster True Color într-un raster codificat pe biți/pixel, ceea ce îl va reduce la o treime din dimensiunea inițială, precum și poate beneficia de compresia RLE De asemenea, puteți converti un raster de biți în biți Când lucrați cu un tabel sau o paletă de culori, cel mai simplu mod de a reduce profunzimea culorii se reduce la un algoritm pentru găsirea celei mai apropiate culori Culoarea fiecărui pixel din raster este comparată cu toate culorile din tabel; indexul celei mai apropiate potriviri este luat ca noua valoare a pixelului din noul raster Lista - arată clasa KColorMatch, care implementează o căutare de culori liniară cu forță brută Metoda KColorMatch::ColorMatch caută într-o serie de structuri RGBQUAD cea mai apropiată culoare de cea specificată în spațiul de culoare RGB Lista Clasa KColorMatch: Potrivire simplă a culorilor clasa KColorMatch { public: RGBQUAD*m Culori: int mjiEntries; int pătrat (int i) { întoarce i * i; } public: BYTE ColorMatch (int roșu, int verde, int albastru) { int dis = x FFFFFFF; BYTE cel mai bun = ; if ( red ) red= ; dacă (verde ) verde= : if ( albastru ) albastru= ; pentru (int i= ; i dis) continuă: d += pătrat(verde - m Culori[i] rgbVerde): dacă (d>dis) continuă: d +- pătrat(albastru - m Culori[i] rgbAlbastru): Reducerea adâncimii de culoare a unui raster dacă ( d bmiHeader biWidth + ) / * : // biți // linia de scanare Int headsize = slzeof(BITMAPINFOHEADER) + * sizeof(RGBQUAD); BITMAPINFO * pNewDIB = (BITMAPINFO *) new BYTECheadsize + m nBPS * abs(pDIB->bmiHeader biHeight)]: memset(pNewDIB headsize): = sizeof(BITMAPINFOHEADER): = pDIB->bmiHeader biWidth: pNewDIB->bmi Header bi Si ze pNewDIB->bmi Header bi Wi dth pNewDIB->bmiHeader biHeight = pDIB->bmiHeader biHeight: pNewDIB->bmiHeader biPIanes = : pNewDIB->bmiHeader biBitCount = ; pNewDIB->bmiHeader biCompression = BI RGB: memset(pNewDIB->bmiColors , * sizeof(RGBQUAD)): int frec[ ]; m Matcher Setup(GenPalette(pDIB pNewDIB->bmiColors, frec ) pNewDIB->bmiColors); m pBits = (BYTE*) & pNewDIB->bmiColors[ ]: dacă (pNewDIB==NULL) returnează NULL: Klmage dib: dib AttachDIB(pDIB NULL ): dib PixelTransform(* this): returnează pNewDIB; Clasa KColorReduction oferă aproape același rezultat ca atunci când redați un raster folosind GDI fără a aplica modul HALFTON Nu este surprinzător, deoarece GDI folosește aproape același algoritm, deși mai bine optimizat În modul HALFTON, GDI poate folosi semitonuri pentru a crea tranziții line între tonurile de culoare Algoritmul de potrivire cel mai apropiat selectează culoarea pentru fiecare pixel independent de ceilalți, în timp ce algoritmul în tonuri de gri încearcă să genereze blocuri de pixeli a căror culoare medie aproximează culoarea imaginii originale Modul de scalare HALFTON este acceptat numai pe sistemele din familia NT Algoritmul în tonuri de gri utilizat de GDI se bazează pe amestecarea simplă a culorilor Există algoritmi mai buni - de exemplu, algoritmul de difuzie a erorilor Floyd-Steinberg În acest algoritm, culoarea fiecărui pixel este însumată cu o eroare acumulată, inițial egală cu Culoarea rezultată este potrivită în tabelul de culori în mod obișnuit, iar indexul returnat este stocat în rasterul final Principal de la Reducerea adâncimii de culoare a unui raster Diferența față de algoritmul GDI constă în distribuția discrepanței dintre culoarea sursă și cea găsită asupra pixelilor vecini, ceea ce afectează selecția culorilor pentru acești pixeli În algoritmul Floyd-Steinberg, eroarea este împărțită în patru părți inegale ( / , / , / și / ) adăugate la patru pixeli adiacenți Pentru a reduce numărul de modele de grilă care apar la amestecare, liniile de scanare pare și impare sunt scanate în direcții opuse Pe fig Figura prezintă distribuția erorilor în algoritmul Floyd-Steinberg P / / / / / / / / Scanare înainte Scanare inversă Orez Distribuția erorilor în algoritmul Floyd-Steinberg Lista - arată implementarea noastră a algoritmului de distribuție a erorilor Clasa KErrorDiffusionColorReduction derivă din clasa KCoIog-Reduction, care ne permite să folosim potrivirea culorilor gata făcută și codul raster de biți În loc de funcția de mapare a pixelilor, mecanismul de procesare a liniei de scanare pe de biți este redefinit Algoritmul de disipare a erorilor are nevoie de variabile suplimentare pentru a stoca eroarea acumulată și un flag care controlează direcția în care este scanat șirul Implementarea algoritmului la nivelul liniei de scanare ar părea mult mai simplă și ar rula mai rapid, dar pentru a fi completă, trebuie să oferim implementări pentru liniile de scanare în alte formate Lista Algoritmul de dispersie a erorilor Floyd-Steinberg clasa KErrorDiffusionColorReduction : public KColorReduction { int * red error; int * green error; int * blue error; bool m bForward; virtual bool StartL ne (linie int) { m pPixel = m pBits + linie * mjiBPS; // Primul pixel al liniei m bForward = (linie & ) == ; returnează adevărat; } Continuare Capitolul Lista Continuare virtual vold Map bpp(BYTE * pBuffer, int width): public: BITMAPINFO * Convert bpp(BITMAPINF * pDIB): inline void ForwardDistribute(int error, int * curerror, int & nexterror) { if ( (eroare - ) || (eroare> ) ) // Eroare - nu este distribuită { nexterror = curerror[l] + eroare * / : curerror[-l] += eroare * / : // X / curerror[ ] += eroare * / : // / / / curerror[ ] += eroare / : } altfel nexterror = curerror[l]: } inline void eroare BackwardDistributednt int * curerror, int & nexterror) { if ( (eroare ) ) // Eroare - nu este distribuită { nexterror = curerror[-l] + eroare * / : curerror[ ] += eroare * / : // / X curerror[ ] += eroare * / : // / / / curerror[-l] += eroare / : } altfel nexterror = curerror[-l]: } BITMAPINFO * KErrorDiffusionColorReduction::Convert bpp(BITMAPINF * pDIB) int extwidth = pDIB->bmiHeader biWidth + : int * eroare = nou int[extwidth* ]: memset(eroare, , sizeof(int) * extwidth * ); red error = eroare + : green error = red error + extwidth; blue error = green error + extwidth: BITMAPINFO * pNew = KColorReduction::Convert bpp(pDIB): eroare de ștergere[]: returnează pNou; Reducerea adâncimii de culoare a unui raster void KErrorDiffusIonColorReduction::Map bpp(BYTE * pBuffer, int width) { int next red, next green, next blue; dacă ( m bForward ) { next red = red error[ ]; next green = green error[ ]; următorul albastru = blue error[ ]; pentru (int = ; i = ; ) { int red = pBuffer[ ]; int verde = pBuffer[l]: int albastru = pBuffer[ ]: Potrivire BYTE = m Matcher ColorMatch( red+next red, green+next green, blue+next blue ); BackwardDistribute(roșu - m Matcher m Colors[potrivire],rgbRed red error +i, next red); BackwardDistribute(verde - m Matcher m Colors[match] rgbGreen, green error+i next green): BackwardDistribute(albastru - m Matcher m Colors[match] rgbBlue, blue error +i next blue): Continuare^ Capitolul Lista Continuare * m pPixel = potrivire; pBuffer -= ; } } } Clasa de dispersie a erorilor conține patru variabile suplimentare Trei dintre ele stochează matrice de eroare pentru canalele RGB Funcția Convert bpp alocă memorie pentru matrice din heap și o inițializează la zero Rețineți că inițializarea asigură că red error[-l] și red err[width] pot fi indexate pentru a evita verificarea limitelor la distribuirea erorii Variabila m bForward specifică direcția de scanare a liniei de scanare (înainte sau înapoi), valoarea acesteia este atribuită de funcția StartLine Două funcții în linie, ForwardDistribute și BackwardDistribute, distribuie eroarea pe trei canale Ei primesc eroarea curentă și un pointer către poziția curentă în matricea de erori și returnează următoarea valoare de eroare În fiecare linie de scanare, funcția Mar Bpp însumează componentele de culoare ale fiecărui pixel cu erorile de canal, potrivește culoarea, apoi distribuie erorile și trece la următorul pixel Algoritmul Error Scattering oferă un rezultat mult mai bun decât cel mai apropiat algoritm de potrivire a culorilor și, în majoritatea cazurilor, mai bun decât algoritmul GDI în tonuri de gri Un avantaj suplimentar este că poate folosi orice paletă, în timp ce algoritmul GDI în tonuri de gri funcționează de obicei cu mai puține culori Rezultate Acest capitol este dedicat problemei obținerii de imagini color de înaltă calitate pe dispozitive grafice cu un set limitat de culori Pentru a rezolva această problemă, aplicația trebuie să se ocupe de palete, să le partajeze cu alte aplicații, să construiască palete conform tabelului de culori raster, să cuantizeze și să reducă adâncimea culorii În viitorul apropiat, paletele vor continua să fie relevante pentru aplicațiile de pe piața de masă Dacă o aplicație folosește mai mult de de culori, designul și implementarea ar trebui să țină cont de paletă Grafica vectorială tind să fie mai puțin o problemă decât grafica raster, deoarece de obicei folosesc mai puține culori În aplicațiile normale, o paletă de semitonuri cu o distribuție uniformă a culorilor oferă de obicei un rezultat destul de bun Cu toate acestea, în aplicațiile care funcționează cu grafică de înaltă calitate sau afișează un număr mare de culori în același timp, o paletă specializată optimă poate îmbunătăți semnificativ calitatea graficii în comparație cu tonurile de gri Rezultate Paletele sunt, de asemenea, acceptate pentru suprafețele DirectDraw, ceea ce permite programelor de joc să creeze efecte speciale de animație bazate pe modificările paletei, să reducă costurile de memorie sau pur și simplu să îmbunătățească performanța pe computerele low-end Cunoașterea noastră cu rasterele și paletele a luat sfârșit În capitolul următor, trecem la un subiect complet nou - fonturile și lucrul cu textul Exemplu de program Capitolul este însoțit de programul Palette, care ilustrează tot materialul prezentat (Tabelul ) Tabelul Programul capitolului Descriere director de proiect Samples\Chapt \Palette Demonstrație de lucru cu paleta de sistem, procesare paletă de mesaje, aplicarea paletelor de semitonuri, culori web și tonuri de gri, schimbarea modului video, construirea unei palete bazate pe un bitmap, cuantificarea culorilor, distribuirea erorilor și așa mai departe Capitolul Fonturi Acest capitol începe introducerea noastră în fonturi și operațiuni de text în programarea grafică Windows Fonturile și utilizarea lor în tipărire au o istorie lungă și interesantă Cu mult timp în urmă, în î Hr , indienii stăpâneau fabricarea timbrelor sculptate În jurul anului d Hr , chinezii au învățat cum să lase ștampile de cerneală pe hârtie, ceea ce a marcat începutul tipăririi moderne a cărților În , chinezii au dezvoltat o tehnică de imprimare folosind caractere de lut, iar în , coreenii au trecut la caractere metalice Două secole mai târziu, în , Gutenberg a inaugurat o nouă eră în tipărire Odată cu invenția sa - tiparnița - a început producția în masă a literelor tipografice folosite la tastarea paginilor de text Din acel moment, un set complet de caractere de o singură literă și dimensiune a fost numit „font” în tipărire În , un anume profesor a decis să publice o a doua ediție a cărții sale, publicată cu câțiva ani mai devreme folosind aceleași matrice de plumb ca și Gutenberg Spre surprinderea lui, a aflat că vechea tehnologie devine treptat un lucru al trecutului, iar cea nouă, mașinile de tipografie foto-optice, nu oferă încă o calitate acceptabilă Profesorul a refuzat să folosească o astfel de tehnologie imperfectă pentru a prezenta roadele celor ani de muncă asiduă și s-a apucat să rezolve vechile probleme tipografice bazate pe tehnologia computerizată Patru ani mai târziu, a dezvoltat un nou mod de a descrie fonturile cu formule matematice, ceea ce a dus la apariția unor sisteme de tipărire cu drepturi depline Cu ajutorul unuia dintre aceste sisteme și-a publicat lucrarea, a cărei publicare a fost amânată cu ani Numele profesorului era Donald E Knuth, programul de fonturi se numea METAFONT, iar pentru layout a fost folosit pachetul TeX Mai mult decât atât, toate roadele muncii lui Knuth, împreună cu textele sursă complete, erau disponibile pentru toată lumea, astfel încât utilizatorii din întreaga lume să poată crea fonturi pentru orice limbă și să creeze machete de cărți electronice Fonturile și textul au fost în mod tradițional considerate un subiect extrem de complex Acest capitol este despre fonturi, iar următorul este despre operațiunile text În acest capitol noi Ce este un font? Să ne uităm la seturi de caractere, codificări, glife, fonturi în general și varietatea lor specifică - Tipul fonturilor, precum și tehnologia de încorporare a fonturilor Ce este un font? Dispunerea computerelor a fost întotdeauna considerată una dintre principalele domenii de aplicare a computerelor personale În anii de școală și de-a lungul vieții, cu toții trebuie să creăm tot felul de documente și să pregătim cărți pentru publicare Procesul de aranjare a computerului depinde în mare măsură de suportul pentru fonturi și operațiuni de text la nivelul sistemului de operare Cu toate acestea, fonturile și textul nu se numără printre funcțiile de bază ale sistemelor de grafică pe computer - în unele cărți dedicate fundamentelor teoretice ale graficii pe computer, ele nu sunt menționate deloc Mai degrabă, fonturile și textul ar trebui privite ca obiecte de aplicare a principiilor generale pentru rezolvarea unei întregi clase de probleme practice De regulă, instrumentele de font și text ale sistemului de operare sunt implementate folosind primitive grafice de bază (pixeli, linii, curbe, forme și raster) Puteți chiar să vă creați propriile instrumente de font și text pe baza acestor primitive Unul dintre instrumentele principale ale aspectului computerului sunt fonturile - un fel de șablon pentru reprezentarea caracterelor limbii cu care lucrați În mod tradițional, un font este definit ca un set complet de caractere de un tip și o dimensiune, care corespunde specificului utilizării unui font în tipografie O literă este un bloc dreptunghiular (de obicei metal), pe suprafața frontală a căruia există o imagine în relief a unui personaj Tehnologiile digitale au extins semnificativ sensul termenului și posibilitățile fonturilor În această secțiune, vom acoperi conceptele și termenii de bază legați de lucrul cu fonturile în contextul programării grafice Windows Seturi de caractere și codificări Un set de caractere în Windows este definit pur și simplu ca o colecție de caractere Fiecare set are un nume și un identificator numeric De exemplu, setul de caractere standard Windows se numește ANSI CHARSET, are un identificator de și conține caractere în setul de caractere ANSI standard pe biți definit de Windows pentru limbile occidentale Fereastra de sesiune DOS folosește OEM CHARSET cu ID ; conține aceleași caractere ANSI pe biți cu caractere suplimentare care au fost definite de IBM în primele zile ale DOS Seturile de caractere cu identificatori pe un singur octet nu sunt o soluție bună, mai ales în era comunicațiilor electronice globale pe Internet Au fost înlocuite de conceptul de codificări, sau pagini de coduri (pagini de coduri) O codificare este o schemă de reprezentare a caracterelor din Capitolul Fonturi un set dat de unul sau mai mulți octeți de informații Astfel, din punct de vedere formal, o codificare este o mapare a unei secvențe de biți într-un set de caractere Codificările, spre deosebire de seturile de caractere, sunt notate prin identificatori numerici de doi octeți, care oferă suport pentru mai multe limbi În tabel Tabelul listează seturile de caractere și codificările lor corespunzătoare acceptate de sistemul de operare Windows Primele seturi, de la SHIFJIS CHARSET la EASTEUROPE SET, sunt asociate cu codificări într-o corespondență unu-la-unu De exemplu, setul SHIFTJIS CHARSET folosește (JIS înseamnă standardul japonez al industriei) Setul de caractere GB CHARSET corespunde codării (GB este o abreviere pentru standardul național chinez) Ultimele trei seturi, ANSI CHARSET, OEM CHARSET și MAC CHARSET, au codificări diferite în funcție de contextul de sistem/proces local Acestea sunt mapate la diferite codificări, în funcție de locul în care se află cu adevărat computerul dvs sau cel puțin de unde „crede” computerul că este Dacă contextul local implicit este engleză, atunci ANSI CHARSET corespunde codificării , OEM CHARSET corespunde codificării , iar MAC CHARSET corespunde codificării Tabelul Seturi de caractere și codificări Numele setului de caractere ȘI identificatorul setului de caractere Utilizare codificare SHIFTJIS-CHARSET Japoneză Japonia HANGUL CHARSET Coreea Coreea JOHAB CHARSET GB CHARSET Chineză (simplificată) China, Singapore CHINESEBIG CHARSET chineză (tradițională) Taiwan, Hong Kong GREEK CHARSET Greacă (Windows) TURKISH-CHARSET , Turcă (Windows) Turcia VIETNAMESE CHARSET vietnameză (Windows) HEBREW CHARSET ebraică (Windows) ARABIC CHARSET arabă (Windows) BĂLTIC CHARSET Baltic (Windows) Ce este un font? Numele setului de caractere Identificatorul setului de caractere Codificare Utilizare RUSSIANCHARSET Chirilic (Windows) Țări slave THAI CHARSET Thai EASTEUROPE CHARSET , Windows Latin Europa Centrală ANSI CHARSET , Windows Latin , Windows Latin , arabă (Windows) SUA, Marea Britanie, Canada etc Ungaria, Polonia etc Irak, Egipt, Yemen etc OEM CHARSET , MS DOS Latin , MS DOS Latin , MS DOS arabă SUA, Marea Britanie, Canada etc Ungaria, Polonia etc Irak, Egipt, Yemen etc MAC CHARSET , Mac (țări vorbitoare de limbă engleză) , Mac (Europa Centrală) , Mac (chirilic) SUA, Marea Britanie, Canada etc Ungaria, Polonia etc Ucraina, Rusia etc Majoritatea codificărilor conțin de caractere Un caracter din ele este reprezentat de un singur octet, astfel încât aceste codificări sunt numite codificări pe un singur octet Primele de caractere ale unei codări pe un singur octet sunt de obicei aceleași cu caracterele ANSI pe biți Primele de caractere corespund codurilor de control neafișate, urmate de un spațiu, simboluri matematice și de serviciu, numere și litere ale alfabetului englez în litere mari și mici Conținutul următoarelor de caractere variază foarte mult în funcție de codificare Aici sunt stocate literele alfabetelor naționale, semnele suplimentare, simbolurile pseudografice și chiar și semnul euro recent apărut Pe fig arată conținutul codificării (Windows Latin ) După cum se poate observa din figură, a doua jumătate a codificării conține simboluri ale alfabetelor naționale, bancnote, apostrofe și ghilimele etc Unele simboluri marcate cu dreptunghiuri goale nu sunt folosite Primul caracter, x , a fost recent atribuit semnului euro Pentru comparație, în fig arată codificarea Windows pentru lucrul cu chirilic ( ) Vă rugăm să rețineți că semnul euro este într-o poziție diferită, deoarece caracterul cu codul x este deja preluat Capitolul Fonturi douăzeci treizeci cincizeci SA F D EO ÎN ASA DE □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ II # $ % ( ) * + - / @ A c D E FG H IJ k L m N p QRS T și VWXYZ [ \ ] L a b c d e fgh i j k W P o p q G S t și VWX Y Z { } □ € □ / ■»> t І °/oo S se □ ZY eu £ o ¥ § © a « - - ® — ± I o » d l/s % Â Â Â Ă A Â Q Ё Ё Ё І І i Î Î DN o b b b X i i i i Y c a a c a a a ae ё ё ё і i i н i ă p aproximativ despre b b -n și y și U U U U U Orez Codificare Windows Latin ( ) douăzeci DO EO F SA ÎN ASA DE treizeci cincizeci □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ □ — ! II # $ % ( ) * + - / ? @ A B c D E FG H IJ k L m N o p QRS T și VWXYZ [ \ ] A a b c d e fgh i j k m p o p q G S t și VWX Y Z { } □ ъ г г , t + + € % l> k ъ c s • — — □ tm JL > H> K h c Y Y J g § E © e « - - ® I o ± I і r i ё № e » j SS i A B c d e f f i j k l m n p R S t U v X ts h w a y a y a b c d e f g i j k l m n o p r S t U v X Orez Codificare Windows sg iiic ( ) Ce este un font? Deși codificările pe un singur octet sunt suficiente pentru a reprezenta caracterele majorității limbilor lumii, trei limbi orientale conțin prea multe caractere care nu se încadrează în limitele unei codificări pe un singur octet Scrierea chineză folosește mii de caractere, dintre care unele au fost împrumutate din Japonia și Coreea Caracterele unor seturi hieroglifice mari sunt reprezentate de mai mulți octeți, astfel încât astfel de codificări sunt de obicei numite codificări dublu-octeți sau multi-octeți În setul de caractere MultiByte (MBCS), caracterele ASCII pe biți sunt reprezentate de un octet, iar caracterele chinezești, japoneze și coreene sunt reprezentate de doi octeți Un șir de text codificat MBCS este întotdeauna analizat de la stânga la dreapta Dacă primul (prefix) octet este mai mic de ( x ), atunci avem un caracter de un octet din prima jumătate a codificării Windows Latin ( ) Dacă octetul de prefix este de sau mai mare, este necesară o verificare suplimentară, deoarece numai octeții din anumite intervale pot fi utilizați în caractere pe două octeți Dacă octetul de prefix aparține intervalului permis, are loc o verificare suplimentară a celui de-al doilea octet Pentru codificarea utilizată în China și Singapore, ambii octeți trebuie să fie în intervalul [ xA xFE], ceea ce permite reprezentarea a până la de caractere pe dublu octet Codificarea folosită în Coreea este puțin mai complicată În el, octetul de prefix aparține intervalului [ x xFE], iar al doilea octet trebuie inclus într-unul dintre intervalele [ x x a], [ x x a] și [ x OxFE] Numărul de caractere permise crește la prezintă un mic fragment din codificarea tradițională chineză Vă rugăm să rețineți: caracterele chinezești din codificarea sunt sortate după numărul de linii Pe fig prezintă hieroglife relativ simple care nu conţin mai mult de patru rânduri A A A A A A A B A C A D A E A F — Z, t X L t — L d L l L b X -Z t ± YX L L X w ■t pentru A] X □ ± ± XXX f F g ih LI I a c a F - XX ? ? n dacă f Ya "X ~ k X n tС T la U L MT £ X m tu chi % * t E I X F X I L LXR ; E a -i - X i X $ X t X V i X ± X tt Y / K 'K W XX I X NOI ? Orez Fragment de codificare (chineză simplificată) La prima vedere, poate părea că numărul de linii în unele hieroglife este mai mare de patru, dar acest lucru se datorează unor reguli specifice de numărare - Notă transl Capitolul Fonturi Când lucrați cu diferite codificări (în special cele multiocteți) în programe, apar o mulțime de dificultăți De exemplu, chiar și pentru a rezolva cele mai simple sarcini, cum ar fi trecerea la următorul caracter, trebuie să apelați funcția Windows API CharNext în loc să creșteți pur și simplu indicatorul cu Trecerea la caracterul anterior este și mai dificilă - acest lucru este evidențiat prin trecerea unui parametru suplimentar (adresa de pornire a șirului) la funcția CharPrev Mari probleme apar și cu conversia caracterelor între codificări Pentru a rezolva aceste probleme, a fost propus standardul Unicode Dezvoltarea, întreținerea și promovarea standardului de codificare a caracterelor Unicode pe doi octeți este realizată de Consorțiul Unicode Acest consorțiu include Apple, Hewlett-Packard, IBM, Microsoft, Oracle, Sun, Xerox și alte companii Standardul Unicode face posibilă reprezentarea majorității caracterelor scrise din aproape toate limbile lumii Utilizează o reprezentare pe biți fără prefixe sau comutare de mod, permițând exprimarea a până la de caractere În Unicode, un caracter este reprezentat printr-o valoare de biți de la la FFFF (în notație hexazecimală) Simbolurile sunt grupate în zone logice De exemplu, zona corespunde caracterelor de bază ale alfabetului latin cu coduri de la la F Zona conține semne de punctuație comune cu codurile de la la F Cea mai mare zonă, , conține de caractere chinezești utilizate în China, Japonia și Coreea A doua cea mai mare zonă conține caracterele And Hangul folosite în Coreea Pe fig arată caracterele incluse în zona convenției Unicode Di $ la Ѳ L V L și X □ □ □ □ □ □ lu din b ZY & V t s* e f i f o mim ym im o ep s $ V b c? h țp E VV și ѳ SI pu * la? € d â & e I d V ♦ ❖ f ❖ J J l # Orez Zona de caractere Unicode În timp ce sistemul de operare Windows a fost proiectat să accepte mai multe codificări și limbi, anumite codificări și limbi necesită fișiere suplimentare care este posibil să nu fie prezente în instalarea implicită a sistemului Pachetele suplimentare sunt instalate folosind aplicația Setări regionale (Limbă și standarde) din panoul de control, fie de pe CD-ul sistemului de operare, fie de pe site-ul Microsoft Funcția API EnumSystemCodePages enumeră toate paginile de cod acceptate sau instalate pe sistemul dumneavoastră Ce este un font? Glife Seturile de caractere și paginile de cod definesc doar gruparea logică și reprezentarea caracterelor, nu aspectul acestora Un simbol este doar un concept abstract, nu o reprezentare concretă Un simbol desenat pe hârtie ia o formă grafică numită glif De exemplu, în codificarea Windows Latin , litera majusculă engleză A are un index de x , dar poate arăta diferit, așa cum se arată în Fig AAAAAAAAAAAAAALALAAIM Orez Diverse glife pentru litera A Relația dintre glifă și caracter De obicei, există o corespondență unu-la-unu între caractere și glife dintr-un font Un caracter este reprezentat de exact un glif, iar un glif reprezintă exact un caracter Cu toate acestea, acest lucru nu este întotdeauna cazul Există caractere care sunt reprezentate printr-o combinație de mai multe glife, iar același glif poate fi folosit în caractere diferite Astfel de glife sunt tipice caracterelor chinezești sau coreene, care constau adesea din mai multe părți, deși în fonturi de înaltă calitate este mai bine să folosiți mai multe versiuni ale unui singur glif Glifele de caractere se pot schimba și în funcție de contextul în care este scris personajul De exemplu, caracterele care apar la începutul sau la sfârșitul unei propoziții pot fi stilizate cu glife speciale În special, formele contextuale ale glifelor sunt utilizate pe scară largă în limbile arabe, iar atunci când scrieți textul chinezesc pe verticală, orientarea parantezelor se schimbă Dacă unele combinații de caractere sunt adiacente, acestea pot fi convertite într-un singur glif, numit ligatură În general, un caracter este reprezentat de unul sau mai multe glife care pot fi folosite de mai multe caractere; de asemenea, este permisă combinarea mai multor caractere într-o ligatură după reguli speciale Pe fig Figura arată relația dintre caractere și glife Prima linie conține litera O cu diverse semne diacritice, urmată de caractere chinezești cu o tastă stângă comună Aceste exemple arată că un caracter poate corespunde mai multor glife A doua linie arată câteva dintre ligaturile folosite în daneză, norvegiană, franceză și engleză A treia linie arată modul în care parantezele și parantezele pătrate sunt convertite în glife verticale în scrierea tradițională chineză verticală, care continuă să fie folosită la ocazii speciale (cum ar fi invitațiile de nuntă) Ultima linie arată patru grupuri de glife pentru trei caractere arabe Fiecare caracter arab poate avea până la patru glife de context, pentru formele izolate, inițiale, finale și intermediare Capitolul Fonturi bbbbb A+E=/E C+E=CE f+i=fi f+l=fl da) [«] i -k thtawdt Orez Relația dintre personaje și glife Elemente de glifă Glifele cu atribute constante sunt de obicei grupate Pentru literele alfabetului latin, astfel de atribute includ grosimea liniilor, stilul liniilor, serifurile, alinierea liniei de bază, forma ovalelor și buclelor, dimensiunea superscriptelor și a subscriptelor etc O linie de bază este o linie imaginară folosită pentru a alinia vertical glife Literele latine sunt de obicei aliniate la linia de bază; excepția sunt literele cu descendenți (de exemplu, f, g, j și Q) Înălțimea unui x mic se numește înălțimea x și, de obicei, definește înălțimea corpului tuturor glifelor cu litere mici Unele glife minuscule se ridică deasupra înălțimii lui x; descendenții lor se numesc superscripte (ascendent) Unele glife minuscule coboară sub linia de bază; elementele glifei corespunzătoare se numesc descendenți În plus, glifele pot avea serif (serif) - mici linii transversale la capetele liniilor principale Bila mică de la sfârșitul loviturii (ca în literele a, c, f și y) se numește terminator de bilă Un interval intra-litera (contor) este o zonă care este complet sau parțial înconjurată de un glif (ca în literele p, d sau e) Termenul „bol” se referă la forma de bază a literelor, cum ar fi C, G și D Pe fig prezintă câteva elemente ale glifelor serif Înștiințare în indicele element Serif Semioval De bază înălţime Înștiințare pentru indice element lacrimă Decalaj intra-litere Orez Elemente structurale ale unui glif pentru alfabetul latin Ce este un font? Glifele altor limbi pot avea o structură similară sau pot conține elemente diferite moștenite din motive istorice Font După ce v-ați familiarizat cu seturile de caractere, codificări și glife, puteți defini un font Un font este o colecție de glife care au un stil grafic similar, pentru care este definită maparea caracterelor de codificări acceptate la glife Un font poate suporta una sau mai multe codificări; pentru fiecare caracter al fiecărei codificări, se mapează la un grup de glife care formează reprezentarea grafică a caracterului Glifele și regulile pentru maparea caracterelor la glife se numără printre componentele de bază ale unui font Fonturile au multe alte atribute De exemplu, fiecare font are un nume complet (de exemplu, Times New Roman Bold sau Courier New Italic) Numele fonturilor sunt de obicei protejate de drepturi de autor De exemplu, Microsoft deține fontul Wingdings, iar Courier New Italic este deținut de Monotype Corp Fonturile sunt de obicei stocate în fișiere fizice în subdirectorul fonturi din directorul de sistem Panoul de control include o aplicație Fonturi pentru vizualizarea, instalarea și eliminarea fonturilor din sistem Pentru a obține o listă cu toate fonturile instalate pe sistem, trebuie să parcurgeți cheile de registry Fragmentul de mai jos enumeră toate fonturile din sistem și folosește datele colectate pentru a completa lista void ListFonts (KL stView * pList) { const TCHAR Key Fonts[] = JC'SOFTWAREWMicrosoftWWindows NT” „WCurrentVersionWFonts”): HKEY hKey; dacă ( RegOpenKeyEx(HKEY LOCAL MACHINE, Key Fonts, , KEY READ, & hKey)==ERROR SUCCESS ) { pentru (int i= ; ; i++) { TCHAR szValueName[MAX PATH]; BYTE szValueData[MAX PATH]; DWORD nValueNameLen = MAX PATH; DWORD nValueDataLen = MAX PATH; DWORD dwType; if ( RegEnumValue(hKey, i szValueName, & nValueNameLen, NULL, & dwType, szValueData, & nValueDataLen) != ERROR SUCCESS ) pauză; pList->AddItem(O, szValueName); pList->Add!tem(l, (const char *) szValueData); Capitolul Fonturi RegCloseKey(hKey); } } Familie de fonturi și stil Numele unui font definește familia căreia îi aparține și stilul acestuia O familie este un grup de fonturi care au caracteristici similare și sunt unite printr-un nume comun De exemplu, familia Times New Roman constă din patru fonturi diferite: Times New Roman, Times New Roman Italic, Times New Roman Bold și Times New Roman Bold Italic Modificarea unui font într-o familie se numește stil Stilurile comune includ normal, aldin, cursiv, condensat, subliniat, barat etc În loc să creeze fonturi noi, un stil poate fi simulat prin modificarea setărilor pentru glif De exemplu, fonturile create de programul METAFONT al lui Knuth deja menționat depind de mai mult de o duzină de parametri care vă permit să modificați dimensiunea serifurilor, grosimea liniilor etc Sublinierea și bararea în Windows sunt de obicei simulate prin intermediul GDI O familie de fonturi este o abstractizare convenabilă, dar de unde știe o aplicație cărei familii de fonturi îi aparține un anumit font? GDI acceptă steaguri pentru a clasifica familiile de fonturi după caracteristicile de bază ale glifului Aceste steaguri sunt listate în tabel Tabelul Steaguri pentru familie și fonturi Flag Valoare Descriere DEFAULT-PITCH Pasul font arbitrar FIXED PITCH Font cu spații fixe VARIABLE PITCH Font proporțional FF DONTCARE " Font cu atribute personalizate Font FF ROMAN " cu grosime variabilă a liniilor și serifuri FFJWISS " Greutate de linie variabilă Sans Serif Font FF MODERN " cu greutate constantă a liniilor Font FF SCRIPT " Script FF DECORATIVE « Font cu design complicat În fonturile monospace, toate glifele au aceeași lățime Fonturile monospațiate sunt utilizate în mod obișnuit în ferestrele de sesiune DOS, în listări și, în general, oriunde este necesară alinierea verticală În fonturile proporționale, glifele au lățimi diferite; literele i sau ocupă mult mai puțin spațiu decât m Textul afișat cu font proporțional este mai bine perceput de ochiul uman, deci în cărți, electronice Ce este un font? documentația tronului și paginile web folosesc fonturi proporționale Fonturile din familia Roman au greutăți variabile ale liniilor și serif-uri Familia elvețiană folosește greutăți variabile ale liniilor, dar nu serif Familiile de fonturi romane și elvețiene sunt de obicei proporționale Familia Modern conține fonturi cu o greutate constantă a liniilor, de obicei monospațiate Fonturile din familia Script imită scrisul de mână Toate celelalte fonturi exotice sunt atribuite familiei Decorative Pe fig prezintă exemple de fonturi ale unor familii Roman elvețian roman elvețian Modern Modern &Script Script Sccoratîue decorative Roman Roman elvețian elvețian Modern Modern Script Script DECORATIV Orez Clasificarea familiei de fonturi În aplicații, este de obicei mai convenabil să lucrezi cu familii de fonturi decât cu fonturi individuale, deoarece familiile sunt mai mici și mai ușor de ales GDI oferă funcția EnumFontFamiliesEx pentru a enumera toate familiile de fonturi disponibile pe sistem int EnumFontFamiliesEx(HDC hDC LPLOGFONT pLogFont FONTENUMPROC IpEnumFontFamExProc LPARAM Param DWORD dwFlags); Primul parametru este contextul dispozitivului Unele dispozitive grafice (cum ar fi imprimantele laser sau PostScript) pot accepta fonturi hardware care sunt specifice dispozitivului respectiv Al doilea parametru indică o structură LOGFONT, ale cărei câmpuri fCharset și fFaceName definesc setul de caractere și fontul de interes pentru aplicație Dacă specificați setul de caractere DEFAULT CHARSET, familiile de fonturi care acceptă mai multe seturi vor fi listate de mai multe ori Când se specifică un anumit set de caractere, numai familiile de fonturi care conțin categoria specificată de glife sunt incluse în enumerare (de exemplu, pentru setul SYMBOL CHARSET, glife de simbol) Câmpul fPitchAndFami y al structurii LOGFONT trebuie să fie egal cu zero Parametrul IpEnumFontFamExProc indică o funcție globală care trebuie apelată pentru fiecare familie de fonturi enumerabile, ceea ce nu este o soluție bună în stil C++ Totuși, avem un parametru Param cu datele transmise de apelant către funcția de apel indirect; această opțiune poate fi folosită pentru a andoca C++ la Win Ultimul parametru dwFl ags trebuie să fie Funcția EnumFontFamiliesEx joacă un rol cheie în popularea listelor de fonturi disponibile în casetele de dialog ale aplicației Poate fi folosit pentru a lista toate familiile care acceptă un anumit set de caractere sau toate seturile acceptate pentru un anumit tip de caractere Lista Capitolul Fonturi se oferă o clasă de ajutor pentru a lucra cu această funcție Implementarea implicită stochează rezultatele enumerarii într-o listă Lista Enumerarea familiilor de fonturi clasa KEnumFontFamlly { KLIstView * m pL st; Int static CALLBACK EnumFontFamExProc(ENUMLOGFONTEX *lpelfe, NEWTEXTMETRICEX *lpntme, Int FontType, LPARAM IParam) { dacă ( IParam ) return ((KEnumFontFamily *) Param)->EnumProc(lpelfe Ipntme, FontType); altfel returnează FALSE; public: LOGFONT m LogFont[MAX LOGFONT]; int m nLogFont; mjTType nesemnat; virtual Int EnumProc(ENUMLOGFONTEX *lpelfe, NEWTEXTMETRICEX *lpntme Int FontType) if ((FontType și m nType)== ) returnează TRUE; Dacă ( m nLogFont elfLogFont: m pL st->AddItem( (const char *) lpelfe->elfFullName); m pL st->AddItem(l, (const char *) pelfe->elfScrlpt); m pL st->AddItem( , (const char *) pelfe->elfStyle): m pL st->AddItem( , (const char *) pelfe->elfLogFont fFaceName): m pL st->AddItem( , pelfe->elfLogFont fHeight); m pL st->AddItem( , pelfe->elfLogFont IfWldth); m pL st->AddItem( , pelfe->elfLogFont IfWeight); returnează TRUE; void EnumFontFam es(HDC hdc, KLIstView * pLIst, set de caractere BYTE = DEFAULT CHARSET, TCHAR * FaceName = NULL, tip nesemnat = RASTERJONTTYPE | TRUETYPEJONTTYPE | DEVICE FONTTYPE) { m pL st = pLIst; mjiType=tip: LOGFONT Dacă; memset(& If, , slzeof(lf)); Ce este un font? If lfCharSet = set de caractere; f fFaceNameEO] = ; If IfPitchAndFamily = ; dacă (Nume Față) tcscpy(lf lfFaceName, FaceName); Enum FontFam esEx(hdc, & If, (FONTENUMPROC) EnumFontFamExProc, (LPARAM) this, ); }: Pe fig compară rezultatele listării fonturilor și familiile acestora O enumerare a fonturilor bazată pe o căutare în registry listează toate fonturile fizice din sistem Vedem patru fonturi în familia Agria, patru fonturi în familia Courier New și așa mai departe Când sunt enumerate familii, unele familii apar de mai multe ori în listă dacă acceptă seturi de caractere diferite De exemplu, familia de fonturi Agiiai acceptă seturi diferite y BitsOffset + ); dacă ( (ch FirstChar) || (ch>pH->LastChar) ) ch = pH->DefaultChar; ch -=pH->FirstChar; int width = pGlyphEchJ GIwidth: int înălțime = pH->PixHeight: struct { BITMAPINFOHEADER bmiHeader: RGBQUAD bmiColors[ ]: } dib = { { sizeof(BITMAPINFOHEADER) lăţime -helght BI RGB } { { OxFF OxFF OxFF } { } } }■ int bpl - ( lățime + ) / * : Fonturi bitmap BYTEdata[ / * ]; // Suficient pentru x const BYTE * pPIxel = (const BYTE *) pH + pGlyph[ch] Gloffset; pentru (Int = : ? @ÂB CDEF GHI J KLMNOP QRS TUV WX YZ [ \ ] ~ abcdef ghi jk mnopqrstuvwxyz{| }~I IIIIIIIIIIIIIIIIIIIII IIIIIIIII i § '■ © ! « - ® ' * ± g ' și G '* "**%& SHISHSHI î id SH SH « în I SH și â aaaa ă « ț ё e ё iii Ю puncte, x dpi, x pixeli, avgw , maxw , set de caractere / : ; ? ©ABCDEFGHI J K LMNOPQRSTUV WX YZ [ \ ] L abcdef ghi j kl mnopqr st uvwxyz{ | } eu IIIIIIIIIIIIIII [ I ' IIIIIIIIIIIII ÂÂÂĂÂ^QEEfiEÎ î î ÎI DN O Ox tJOOu?bB aâaâaaaețeeeei i î i dhdoood^euuuuyfjy Orez Glife în format bitmap Din exemplul de mai sus, devine clar ce este un font Fontul Bitmap în format Windows este un set de resurse de fonturi concepute pentru diferite dimensiuni Fiecare resursă de font constă din glife bitmap monocrome care se mapează în mod unic la caractere dintr-un set dat de un octet Fonturile bitmap acceptă o mapare simplă a caracterelor setate la indici de glif din gama de caractere acceptate Glifele sunt ușor convertite în formate de bitmap acceptate de GDI și afișate pe dispozitivele grafice Fonturile bitmap stochează, de asemenea, cele mai simple valori de text Capitolul Fonturi Fonturile bitmap sunt potrivite (atât ca calitate, cât și ca viteză) pentru afișarea caracterelor mici pe ecran; acesta este unul dintre motivele pentru care ele încă există Pentru diferite dimensiuni, un font bitmap trebuie să conțină diferite resurse de font De exemplu, fonturile bitmap Windows conțin de obicei resurse pentru dimensiuni de , , , , și de puncte Pentru alte dimensiuni sau dispozitive cu rezoluții diferite, glifele trebuie să fie scalate pentru a se potrivi Scalare raster este întotdeauna o problemă, deoarece scalarea are ca rezultat pixeli noi Pe fig Figura - arată rezultatul scalării unui glif de font bitmap aaaalAAA Orez Scalarea glifului fontului bitmap În acest exemplu, scalarea întregului este efectuată pe ambele axe, ceea ce înseamnă că fiecare pixel al glifului este pur și simplu duplicat de numărul necesar de ori Figura arată clar defectele rezultate Scalare cu un factor fracționar poate duce la caracteristici de grosimi diferite, deoarece unii pixeli vor fi duplicați de n ori, iar alții - n + ori Desigur, scalarea fonturilor bitmap nu atinge o calitate bună pentru afișare și imprimare Trebuie să căutăm alte modalități de a codifica fonturile care oferă o scalare lină, fără defecte Fonturi vectoriale În fonturile bitmap, glifele sunt reprezentate ca bitmap și, prin urmare, nu pot scala bine la dimensiuni mari Într-o altă reprezentare simplă, un glif este descris printr-o serie de segmente de linie, care sunt apoi desenate cu un stilou Astfel de fonturi se numesc vector Pe Windows, fonturile vectoriale folosesc același format de resursă de font fnt și aceeași structură a antetului fontului În fonturile vectoriale moderne, câmpul Versiune al structurii FontHeader este x , iar câmpul Tip este Principalele diferențe dintre fonturile bitmap și vector sunt în formatul de date glif Într-un font vectorial, fiecare glif este descris printr-o serie de coordonate începând de la punctul ( , ) Cu dimensiuni mici ale grilei, doi octeți semnați sunt suficienți pentru a stoca un punct Un marker special x indică începutul unui nou segment Mai formal, descrierea unui glif vectorial în sintaxa BNF este următoarea: Fonturi vectoriale ::= { } ::= { } ;:= x :; = Cu aceste informații, putem scrie propria noastră funcție de redare a glifului de font vectorial folosind GDI: Int VectorCharOut(HDC hDC, int x, int y, Int ch, const KFontHeader * pH, int sx=l, int sy=l) { typedef struct { offset scurt; latime scurta; } VectorGlyph; const VectorGlyph * pGlyph = (const VectorGlyph *) ( (BYTE *) & pH->BitsOffset + ); dacă ( (ch FirstChar) || (ch>pH->LastChar) ) ch = pH->DefaultChar; altfel ch -=pH->FirstChar; int width = pGlyph[ch] width; int lungime = pGlyph[ch+l] offset - pGlyph[ch] offset; signed char * pStroke = (signed char *) pH + pH->BitsOffset + pGlyph[ch] offset; int dx = ; intdy = ; în timp ce (lungime> ) { bool move = fals; dacă ( pStroke[ ]==- ) { mutare = adevărat: pStroke++; lungime if ( (pStroke[ ]== ) && (pStroke[l]== ) && (pStroke[ ]== ) ) se rupe; dx += pStrokeEOJ; dy += pStrokeEl]; daca (muta) MoveToEx(hDC, x + dx*sx, y + dy*sy, NULL); else LineTo(hDC x + dx*sx, y + dy*sy); pStroke += ; lungime -= : } latime de retur * sx; Capitolul Fonturi Versiunile moderne de Windows folosesc trei fonturi vectoriale: Roman, Script și Modern Fonturile vectoriale ocupă de obicei mai puțin spațiu decât fonturile bitmap, deoarece intervalele sunt ușor scalabile și necesită o singură resursă de font Pe fig Figura arată prima jumătate a glifelor din fontul vectorial Script D:\WINNT \Fonts\SCRIPT FON puncte, x dpi, x pixeli, avgw , maxw , set de caractere Orez Glife de font vector În comparație cu glifele de font bitmap, glifele vectoriale se scalează bine, deși pe măsură ce caracterul devine mai mare, cusăturile dintre segmentele de linie dreaptă devin mai vizibile Pe fig Figura arată rezultatul scalării glifei A Orez Scalare a glifului fontului vectorial Grosimea stiloului folosit în desen este proporțională cu dimensiunea glifului; în GDI, glifele vectorului fonturilor sunt desenate cu un creion de un pixel gros În timp ce fonturile vectoriale îmbunătățesc scalarea la dimensiuni mari de caractere, ele tot nu redă glife de înaltă calitate pe dispozitivele grafice de înaltă rezoluție Fonturile TrueType sunt folosite pentru ieșirea textului de înaltă calitate Fonturi Fonturi Înainte de Windows , numai fonturile bitmap și vector erau acceptate pe Windows Scalarea fonturilor bitmap a fost greșită, iar fonturile vectoriale erau prea subțiri, așa că niciuna dintre aceste tehnologii nu a oferit text de înaltă calitate la rezoluții înalte (mai ales atunci când este tipărit pe o imprimantă) Adobe, care a avut dezvoltări tehnologice profunde în domeniul limbajului și fonturilor PostScript, a lansat un „corp străin” - ATM (Adobe Type Manager) în lumea Windows ATM accesează Windows GDI și permite tuturor aplicațiilor Windows să funcționeze cu fonturi ușor scalabile Marginile zdrențuite și liniile subțiri au fost înlocuite magic cu glife netede, profesionale, care arătau la fel pe ecran și pe imprimantă Microsoft a înțeles rapid beneficiile noilor tehnologii de fonturi și, începând cu Windows , Windows a introdus suport pentru tehnologia de fonturi TrueType de la Apple În fonturile TrueType, contururile glifului sunt definite prin linii și curbe, permițându-le să fie scalate la dimensiuni arbitrare, păstrând în același timp forma glifului Există două diferențe principale între fonturile TrueType și fonturile vectoriale În primul rând, curbele fonturilor TrueType rămân netede atunci când sunt scalate, în timp ce în fonturile vectoriale de dimensiuni mari, intersecțiile segmentelor devin vizibile În al doilea rând, fonturile vectoriale definesc liniile, în timp ce fonturile TrueType definesc contururile glifurilor Structura glifului este mult îmbunătățită, astfel încât fonturile TrueType stochează informații suplimentare care le oferă avantaje față de tehnologiile mai vechi de fonturi Windows Să începem prin a privi elementele de bază ale tehnologiei TrueType Format de fișier cu font TrueType Un font TrueType este de obicei stocat într-un singur fișier TTF Sistemul de operare Windows a introdus recent suport pentru fonturile OpenType, care sunt fonturi PostScript codificate într-un format similar cu TrueType Fișierele cu font OpenType au extensia OTF De asemenea, tehnologia OpenType vă permite să combinați mai multe fonturi OpenType într-un singur fișier Aceste fonturi, numite „colecții TrueType”, folosesc extensia TTC Un font TrueType este codificat în formatul de resursă de font contur Macintosh cu o etichetă unică „sfiit” Formatul de resurse pentru font Bitmap Macintosh (eticheta „NFNT”) nu este utilizat de Windows Un font TrueType începe cu un mic catalog de fonturi cu informații despre zeci de tabele care îl urmează Catalogul de fonturi conține numărul versiunii formatului fontului, numărul de tabele și o structură TableEntry pentru fiecare tabel Structura TableEntry stochează eticheta de resurse, suma de control, offset-ul și dimensiunea fiecărui tabel Următoarea este definiția unui catalog de fonturi TrueType în C structuri typedef { chartag[ ]; Capitolul Fonturi Sumă de verificare ULONG: ULONG offset; lungime LONG; } TableEntry; typedef struct { Sftversion fix; // x pentru versiunea USHORT numTables; USHORT searchRange; USHORT entrySelector; USHORT rangeShlft; înregistrări în tabel[l]; // Cantitate variabilă de TableEntry } TableDirectory; Mulți programatori Windows nici măcar nu știu că fonturile TrueType au fost dezvoltate inițial de Apple pentru sistemele de operare care rulează pe Motorola în loc de procesoare Intel Toate aceste fonturi TrueType folosesc o codificare care plasează pe primul octet cel mai semnificativ Dacă un font TrueType începe cu , știm că avem o resursă de font contur ("sfnt") în formatul versiunea cu de tabele Ultimul câmp al structurii TableDirectory stochează o matrice cu lungime variabilă de structuri TableEntry, o structură pentru fiecare tabel din font Fiecare tabel de fonturi TrueType conține informații separate din punct de vedere logic, cum ar fi datele de glif, maparea caracter-la-glif, datele de kerning și așa mai departe Unele tabele sunt obligatorii, altele sunt opționale În tabel listează cele mai comune tabele găsite în fonturile TrueType Tabelul Tabelele de fonturi TrueType de bază Nume etichetă Descriere head Titlu font Informații globale despre font veche Maparea dintre codurile de caractere și glife Maparea codurilor de caractere la indici de glife giyf Glyph table Definirea conturului glifului și instrucțiuni pentru plasarea lui pe grilă tahr Max profile Rezumat font pentru alocarea memoriei mmtx Valori orizontale Valori orizontale ale glifului loca Index table Convertiți indexul glifului în offset de date în tabelul glifului cale Tabel de nume Informații privind drepturile de autor, numele fontului, numele de familie, stilul etc hhea Structura orizontală Structura orizontală a glifelor: spațiere în indice, spațiere în indice etc Fonturi Tgyeture Ter Nume Descriere hmtx Valori orizontale Lățimea completă și umplutură din stânga kern Tabel de kerning Matrice de perechi de kerning date PostScript PostScript Element de tabel FontInfo și nume PostScript pentru toate glifele Date PCLT PCL Date de font pentru limbajul imprimantei HP PCL : numărul fontului, pasul, stilul etc Valori specifice OS/ OS/ și Windows Set necesar de valori pentru fontul ThieType Toate structurile TableEntry din structura TableDirectory trebuie sortate după numele etichetei De exemplu, structura „stea” trebuie să vină înaintea structurii „cap”, care la rândul său trebuie să vină înaintea structurii „glyf” Locația tabelelor în fișierul de font ThieType poate fi arbitrară Există o funcție în API-ul Win care permite unei aplicații să solicite date despre fontul ThieType: DWORD GetFontDataCHDC hDC, DWORD dwTable DWORD dwOffset LPVOID IpvBuffer DWORD cbData); Funcția GetFontData returnează informații despre fontul ThieType corespunzătoare fontului logic curent selectat în contextul dispozitivului, astfel încât i se trece mânerul contextului dispozitivului în loc de mânerul fontului logic Puteți solicita informații fie despre întregul fișier ThieType, fie despre unul dintre tabelele acestuia Pentru a solicita informații despre întregul fișier, treceți în parametrul dwTable; pentru a obține informații despre un tabel, se trece eticheta acestuia, formată din caractere, în format DWORD Parametrul dwOffset conține offset-ul de început al tabelului sau pentru întregul fișier Adresa este transmisă în parametrul IpvBuffer, iar dimensiunea bufferului este transmisă în parametrul cbData Dacă sunt trecute NULL și în ultimii doi parametri, GetFontData returnează dimensiunea fișierului de font sau a tabelului; în caz contrar, datele sunt copiate într-un buffer oferit de aplicație Următoarea funcție solicită fontul ThieType: TableDirectory * GetTrueTypeFont(HDC hDC DWORD & nFontSize) { // Solicitați dimensiunea fontului nFontSize = GetFontData(hDC , NULL ); TableDirectory * pFont = (TableDirectory *) nou BYTE[nFontS ze]; Dacă (pFont==NULL) returnează NULL; GetFontData(hDC pFont, nFontSize); returnează pFont; Capitolul Fonturi Funcția GetFontData este destinată aplicațiilor care încorporează fonturi TrueType în documentele lor, astfel încât acestea să poată fi citite pe un alt computer unde fontul este posibil să nu fie prezent Se așteaptă ca aplicația să solicite date despre font, să le stocheze ca parte a documentului și să instaleze fontul atunci când documentul este deschis Drept urmare, documentul arată la fel ca pe computerul pe care a fost creat De exemplu, spooler-ul Windows NT/ încorporează fonturi TrueType în fișierele spool atunci când tipăriți pe server, astfel încât documentul să se imprime corect pe alt computer După primirea fontului TrueType, analiza structurii antetului TableDirectory nu va cauza probleme Este suficient să verificați versiunea și numărul de tabele, după care puteți trece la verificarea tabelelor individuale Vom lua în considerare cele mai importante și interesante tabele Font antet Antetul fontului (tabelul „head”) conține informații globale despre fontul TrueType Definiția structurii antetului este dată mai jos typedef struct { masa fixa; // x pentru versiunea font fixRevision; // Setat de dezvoltatorul fontului ULONG checkSumAdj ustment; ULONG magicNumber; // Este egal cu x F F CF USHORT unitsPerEm; // Interval valid longDT creat; // Data în format internațional ( biți) longDT modificat; // Data în format internațional ( biți) FWord xMip; // Pentru toate casetele de delimitare cu glif FWord yMin; // Pentru toate casetele de delimitare cu glif FWord xMax; // Pentru toate casetele de delimitare cu glif FWord min; // Pentru toate casetele de delimitare cu glif USHORT macStyle; USHORT owestRecPPEM; // Dimensiunea minimă lizibilă în pixeli SHORT fontDirect onHint; SHORT IndexToLocFormat: // - offset scurt - lung SCURT glyphDataFormat; // pentru formatul curent } Table head; Istoricul fonturilor (numărul versiunii, data creării și ultima modificare) este stocat în trei câmpuri Datele sunt stocate în câmpuri de octeți ca număr de secunde de la miezul nopții de ianuarie , așa că nu trebuie să ne îngrijorăm niciodată cu privire la „problema Y K” (și chiar la „problema Y M”) Fontul este construit pe o grilă de referință numită e-pătrat; glifele fonturilor sunt descrise de coordonatele acestei grile Prin urmare, dimensiunea grilei de referință afectează scalarea fontului și calitatea acestuia Antetul fontului stochează dimensiunile pătrate em și datele casetei de delimitare ale tuturor glifelor Dimensiunile Em-pătratului pot varia de la la , deși valorile de , și sunt utilizate în mod obișnuit , ] Fonturi Printre alte date, tabelul antetului fontului stochează dimensiunea minimă a fontului lizibil în pixeli, indicația de direcție a fontului, indexul glifului în formatul tabelului index, formatul datelor glifului și așa mai departe Profil maxim Fontul TrueType are o structură foarte dinamică Poate conține un număr variabil de glife, descrise de un număr diferit de puncte de întrerupere și un număr necunoscut de instrucțiuni Tabelul de profil maxim (tabelul Shahr) conține date despre costul memoriei pentru rasterizarea fonturilor, astfel încât să poată fi alocată suficientă memorie înainte de a utiliza fontul Deoarece viteza este un factor critic în rasterizarea fonturilor, structurile dinamice, cum ar fi matricea Carry MFC, care trebuie să copieze frecvent datele, nu sunt potrivite Următoarea este o structură care descrie profilul maxim al fontului typedef struct { Verslon flexibil: USHORT numGlyphs: USHORT maxPoints: USHORT maxContours: USHORT maxCompositePoints: USHORT maxCompositeContours: USHORT maxZones: USHORT maxTwilightPoints: USHORT maxStorage: USHORT maxFunctionDefs; USHORT maxInstructionDefs: USHORT maxStackElements: USHORT maxSizeOflnstructions; USHORT maxComponentElements: USHORT maxComponentDepth: } Tablejnaxp: // x pentru versiunea // Numărul de glife din font // Număr maxim de puncte într-un glif simplu // Contururi maxime într-un glif simplu // Numărul maxim de puncte într-un glif compus // Max contururi într-un glif compus // Numărul de blocuri de stocare // Numărul de FDEF // Numărul IDEF-urilor // Adâncimea maximă a stivei // Max octeți în instrucțiunile pentru glif // Număr maxim de componente de nivel superior // Adâncimea maximă a recursiunii Câmpul numGlyphs stochează numărul total de glife din font, care determină dimensiunea indexului glifului în tabelul de index și este, de asemenea, folosit pentru a verifica indecși Glifele fonturilor TrueType sunt împărțite în compuse (compozite) și simple (necompozite) Un glif simplu constă dintr-una sau mai multe căi, fiecare definită de mai multe puncte de control Un glif compus este definit ca rezultat al combinării altor glife Câmpurile maxPoints, maxContours, maxCompositePoints și maxCompositeContours stochează date despre complexitatea definițiilor glifurilor Pe lângă definițiile pictogramelor, fonturile TrueType folosesc instrucțiuni pentru a rasteriza fonturile Instrucțiunile ajustează poziția punctelor de întrerupere astfel încât glifele rasterizate să fie echilibrate și să arate bine Instrucțiunile Glyph pot fi, de asemenea, stocate global într-un tabel cu fonturi de program ("fpgm") și un tabel cu valori de control al programului ("prep") Instrucțiunile pentru simbol TrueType sunt scrise în bytecode al unei pseudo-mașini de stivă (cum ar fi Java Virtual Machine) câmpurile maxStackElements Capitolul Fonturi și maxSizeOfInstructions spun mașinii de stivă complexitatea acestor instrucțiuni Exemplu: fontul Wingding conține de glife, numărul maxim de contururi dintr-un glif este și numărul maxim de puncte dintr-un glif simplu este Glifele compuse conțin până la de puncte și contururi În cel mai rău caz, ieșirea va necesita de niveluri pe stivă, iar cea mai lungă instrucțiune este formată din octeți Maparea caracterelor la indici de glif Tabelul de mapare caracter la glif (tabelul „stea”) determină corespondența dintre caracterele diferitelor pagini de cod și indexul glifului - o caracteristică cheie pentru obținerea de informații despre un glif într-un font ThieType Tabelul „stea” poate fi compus din mai multe sub-tabele pentru a suporta diferite platforme și codificări de caractere Mai jos este o descriere a structurii tabelului „stea” typedef struct Platformă USHORT: // ID platformă USHORT EncodingID: // Identificator codificare ULONG TableOffset: // Codificare offset tabel } subhartă: typedef struct { USHORT TableVersion: // Versiunea USHORT NumSubTable: // Numărul de tabele de codificare submap TableHeadEU: // Anteturile tabelelor de codificare } Table cmap: typedef struct Format USHORT: // Format: lungime USHORT: // Dimensiune Versiunea USHORT: // Versiune BYTE mapEl]: // Date hartă } Table Encode: Tabelul „vechi” (structura Table cmap) începe cu numărul versiunii, numărul de sub-tabele și titlurile tuturor sub-tabelelor Fiecare subtabel (structură subhartă) conține ID-ul platformei, ID-ul de codificare și offset-ul de date din subtabel pentru platforma și codificarea date Pe sistemele de operare Microsoft, ID-ul platformei este , iar ID-ul de codificare recomandat este (Unicode) Există și alți identificatori de codare - pentru codificarea simbolului, pentru Shift-JIS (Standard industrial japonez), pentru Big (Chineză tradițională), pentru PRC (Chineză simplificată), etc Tabelul de codificare real (Table Encode) începe cu câmpurile format, lungime și versiune, urmate de date de mapare În prezent sunt definite patru formate de tabel diferite Formatul este folosit pentru pro Fonturi codificare stoy care vă permite să afișați până la de caractere Formatul utilizează codificarea pe / biți pentru japoneză, chineză și coreeană Formatul este standard pe sistemele Microsoft Formatul definește o afișare de tabel trunchiată Un font TrueType tipic folosit în Windows conține două tabele de codificare - un tabel de format pe un singur octet pentru maparea caracterelor ANSI la indici de glif și un tabel de format pentru maparea caracterelor Unicode la indici de glif Din punct de vedere conceptual, un tabel de mapare este o structură de date simplă care mapează perechi de numere întregi, dar formatul este prea complex pentru a fi descris în câteva paragrafe Când mapați un cod de caracter la un index de glif din tabel, caracterele lipsă sunt mapate la un glif special la indexul Tabelul „vechi” este de obicei ascuns din aplicație, cu excepția cazului în care doriți să obțineți datele sale folosind funcția GetFontData Windows introduce două caracteristici noi care facilitează accesul aplicațiilor la aceste informații typedef struct { WCHAR wcLow: USHORT cGlyphs; } typedef struct { DWORD cbThls; // sizeof(GLYPHSET) + sizeof(WCRANGE) * (cRanges- ) DWORD flAccel: DWORD cGlyphs acceptate: Variante DWORD: Domenii WCRANGE[l]; // intervale[cRanges]; } GLYPHSET; DWORD GetFontUnicodeRanges(HDC hDC, LPGLYPHSET Ipgs): DWORD GetGlyphIndices(HDC hDC LPCTSTR Ipstr, Int c LPWORD pgi, DWORD f ); De obicei, un font conține glife doar pentru un subset de caractere Unicode, iar aceste caractere pot fi grupate prin spațiere Funcția GetFontUnicodeRanges populează o structură GLYPHSET cu numărul de glife acceptate, numărul de spațiere Unicode și informații suplimentare despre spațiere pentru fontul curent selectat în contextul dispozitivului Structura GLYPHSET are o dimensiune variabilă în funcție de numărul de intervale Unicode pe care le acceptă, astfel încât funcția GetFontUnicodeRanges (ca și alte funcții API Win care acceptă structuri de dimensiune variabilă) este de obicei numită de două ori La primul apel, un pointer NULL este trecut în ultimul parametru; GDI returnează dimensiunea reală a structurii Apelantul alocă un bloc de dimensiunea corectă și apelează din nou funcția pentru a obține datele În ambele cazuri, funcția GetFontUnicodeRanges returnează dimensiunea blocului necesară pentru a stoca întreaga structură Pe MSDN Capitolul Fonturi afirmă că, dacă al doilea parametru este NULL, funcția GetFontUnicodeTanges returnează un pointer către o structură GLYPHSET Următoarea funcție returnează o structură GLYPHSET pentru fontul curent în contextul dispozitivului GLYPHSET *QueryUn codeRanges(HDC hDC) { // Solicitați dimensiunea Dimensiune DWORD = GetFontUnicodeRanges(hDC, NULL): dacă (s ze== ) returnează NULL: GLYPHSET * pGlyphSet = (GLYPHSET *) octet nou[s ze]: // Pentru a obține date pGlyphSet->cbThis = dimensiune: dimensiune = GetFontUn codeRanges(hDC pGlyphSet): returnează pGlyphSet: } Dacă apelați funcția GetFontUnicodeRanges pe unele fonturi Windows TrueType, veți constata că aceste fonturi suportă adesea peste o mie de glife grupate în sute de intervale Unicode De exemplu, fontul Times New Roman conține de glife în de intervale, primul dintre acestea fiind intervalul de coduri ASCII imprimabile pe biți x x F Funcția GetFontUnicodeRanges folosește doar un subset al datelor de font TrueType stocate în tabelul „stea”, și anume informațiile generale despre maparea caracterelor Unicode la indecși de glife Funcția GetGl yphlndices convertește direct un șir de text într-o matrice de indici glife Primește un indicator de context al dispozitivului, un pointer către un șir, lungimea șirului, un pointer către o matrice WORD și un steag Matricea WORD stochează indicii de glif generați Dacă indicatorul este egal cu CGI MASK NONEXISTING GLYPHS, caracterele lipsă sunt înlocuite cu indexul OxFFFF Indicii de glif generați de această funcție pot fi transferați altor funcții GDI, cum ar fi funcția ExtTextOut Tabel index Desigur, cele mai importante date dintr-un fișier cu font TrueType sunt stocate în tabelul de glife ("glyf") Pentru a converti un index de glif într-un decalaj al datelor de glif din tabel, se folosește un tabel de index (tabel „loca”) Tabelul de index conține n + decalaje în tabelul de glife, unde n este numărul de glife stocate în tabelul de profil maxim Decalajul suplimentar de la sfârșit nu indică noul glif, ci sfârșitul ultimului glif Această structură permite fonturilor TrueType să renunțe la nevoia de a stoca lungimea fiecărui glif din font În schimb, rasterizatorul de font calculează lungimea glifului ca diferență între compensarea glifului curent și următorul Indecșii dintr-un tabel de index sunt stocați în format scurt nesemnat sau lung nesemnat, în funcție de valoarea câmpului indexToLocFormat din antetul fontului Gliful trebuie să se alinieze cu o limită scurtă nesemnată; la folosirea scurtă Fonturi Tgyeture offset-ul este stocat în tabel în format WORD în loc de BYTE Acest lucru permite ca tabelul de index de formă scurtă să accepte un tabel de date glif de până la KB Date Glyph Tabelul de glife (tabelul „glyf”) conține cele mai importante informații din întreg fontul ThieType, deci este de obicei cel mai mare Deoarece corespondența dintre indici și glife este stocată într-un tabel separat, tabelul de date cu glife nu conține altceva decât o secvență de glife, fiecare începând cu o structură de antet de glife typedef struct { WORD numberOfContours: // Fword xMIn:// Fword yMin: // Fword xMax: // Fword yMax: // }GlyphHeader: Număr de contururi: numberOfContours): if ( nContour xMi n), invers ((WORD)pHeader->yMin), invers ((WORD)pHeader->xMax), invers ((WORD)pHeader->yMax)): const USHORT * pEndPoint = (const USHORT *) (pHeader+ ): // Total puncte: sfârșitul ultimei trasee + int nPuncte = invers(pEndPoint[nContour- ]) + : // Lungimea instrucțiunilor int nlnst = invers (pEndPoint[nContour]): // Matrice de steaguri: după matricea de instrucțiuni const BYTE * pFlag = (const BYTE *) & pEndPointEnContour] + + nlnst: const BYTE * pX = pFlag: int xlen = : // Analizați o matrice de steaguri pentru a determina // poziția inițială și dimensiunea matricei de coordonate x pentru (int i= : i eMll + y * xm->eM + xm->eDx ), (Int) ( x * xm->eM + y * xm->eM + xm->eDy), (flag & G ONCURVE) ?KCurve:;FLAG ON: ); altfel curba Add(x, y (flag & G ONCURVE) ? KCurve::FLAG ON: ); reprezentant ++; } curbă ÎnchidereO: ) curba de întoarcere GetLength(): } Clasa KTrueType încarcă și decodifică fonturile TrueType; codul complet este pe CD-ul inclus Metoda DecodeGlyph decodifică un singur glif după index și o matrice de transformare opțională Parametrul clasei KCurve este proiectat pentru a asambla definiția glifului într-o matrice simplă de puncte de de biți și o matrice simplă de steaguri, care sunt apoi ușor redate de GDI Puteți chiar să construiți un editor simplu de fonturi TrueType bazat pe această metodă Programul apelează metoda GetGlyph, care utilizează tabelul index pentru a găsi structura GlyphHeader pentru gliful dat Numărul de contururi din glif este preluat din tabel Observați permutarea octeților din valoarea rezultată datorită caracterului endian al octeților din fonturile TrueType Dacă valoarea este negativă (un semn al unui glif compus), este apelată metoda DecodeCompositeGlyph Programul găsește apoi matricea endPtsOfContours, determină numărul total de puncte și omite instrucțiunile la începutul matricei flags Acum trebuie să determinăm punctul de pornire al matricei de coordonate x și lungimea matricei prin iterarea peste matricea de steaguri o dată Fiecare punct poate ocupa de la la octeți în matricea de coordonate, în funcție de dacă offset-ul său relativ este , o valoare de un octet sau o valoare de doi octeți Adresa și lungimea matricei de coordonate x determină adresa matricei de coordonate y Programul iterează apoi toate contururile în secvență, decodifică datele tuturor punctelor, convertește coordonatele relative în coordonate absolute și apoi adaugă punctul la obiectul curbă, aplicând transformarea (dacă există) acestuia Capitolul Fonturi După cum sa menționat mai sus, fonturile TrueType folosesc curbe Bezier de ordinul doi și pot exista mai multe puncte de control între două puncte de pe curbă Pentru a simplifica algoritmul de inferență al curbei, metoda KCurve::Add adaugă un punct de curbă suplimentar între fiecare pereche de puncte de control void Adddnt X int y, steag BYTE) { if ( mjen && ( (flag & FLAG ON)== ) && ( (m Flag[m len-l] & FLAG ON)== ) ) { Adăugați((m Point[mjen- ] x+x)/ , (m Point[m len- ] y+y)/ , FLAG ON | FLAG EXTRA): // Adăugați un punct intermediar } append(x, y flag); } După ce ne-am ocupat de glife simple, să trecem la cele compuse Un glif compus este definit de o secvență de glife transformate Fiecare definiție de glif transformat constă din trei părți: steaguri, index de glif și matrice de transformare Câmpul steagurilor descrie codificarea matricei de transformare (de asemenea, concepută pentru a economisi memorie) și conține, de asemenea, terminatorul secvenței O transformare afină bidimensională completă este definită de șase mărimi Cu toate acestea, pentru o compensare simplă, doar două valori sunt suficiente (dx, dy), care pot fi stocate în doi octeți sau două cuvinte Dacă valorile x și y sunt scalate cu aceeași proporție în același timp cu offset, factorul de scalare poate fi stocat într-o singură instanță În general, toate cele șase valori sunt utilizate, dar în majoritatea situațiilor specifice, câțiva octeți pot fi salvați Parametrii de transformare sunt stocați în format fix ; excepția sunt parametrii dx și dy, care sunt stocați ca numere întregi Un glif compozit este construit prin combinarea mai multor glife, fiecare dintre acestea fiind asociat cu o matrice de transformare De exemplu, dacă un glif este o imagine exactă în oglindă a altui glif, acesta poate fi definit ca un glif compus generat prin aplicarea unei imagini în oglindă unui alt glif Lista arată codul pentru decodarea glifelor compuse Lista KTrueType: :DecodeCompositeGlyph int KTrueType::DecodeCompositeGlyph(const void * pGlyph, KCurve & curve) const { KDataStream str(pGlyph); steaguri nesemnate: int len - : do { steaguri - str GetWordO; gliphIndex nesemnat - str GetWordO; Fonturi Tgyeture argument scurt semnat: argument scurt : if ( steaguri & ARG l AND ARE W RDS ) { argumentl = str GetWord(): // (SHORT sau FWord) argumentl: argument « str GetWordO: // (SHORT sau FWord) argument : } else { argument e (caracter semnat) str GetByteO: argument - (caracter semnat) str GetByteO: } semnat scurt xscale yscale, scaleOl scaleO: xscale " : yscale " : scaleOl " : scalelO = : if ( steaguri și WE HAVE A SCALE ) { xscale « str GetWordO: yscale - xscale:// Format } else if ( steaguri & AVEM AN X AND Y SCALE ) { xscale - str GetWordO; yscale - str GetWordO; } else if ( steaguri & WE AVE A TWO BY TWO ) { xscale - str GetWordO; scaleOl - str GetWordO; scalelO = str GetWordO; yscale - str GetWordO: } if ( flags & ARGS ARE XY VALUES ) { XFORM xm: xm eDx - (float) xm eDy - (float) xm eMll - xscale xm eM " scaleOl xm eM " scalelO xm eM - yscale argumente: argument : / (plutitor) : / (plutitor) : / (plutitor) : / (plutitor) : len +- DecodeGlyph(glyphIndex curve, & xm): } else afirmă (fals): } Continuare & Capitolul Fonturi Lista Continuare while (steaguri și MORE COMPONENTS): If ( flags & WE HAVE INSTRUCTIONS ) // Omite instrucțiuni { unsigned numlnstr = str GetWordO; pentru (nesemnat = ; pO (pO+ pl)/ ( pl+p )/ , p PUNCTUL P[ ] = { { (x + *xl)/ (y + *il)/ } { ( *xl+x )/ ( *il+y )/ } {x y } }; xO = x ; yO = y ; returnează PolyBez erTo(hDC P ): } Pentru o curbă Bezier de ordinul doi definită de trei puncte (p , p p ), punctele corespunzătoare ale curbei Bezier cubice sunt calculate prin formulele (Po, (Po + x P ) / , ( xp, + p ) ) / , p ) Pe fig Figura - arată rezultatul aplicării codului implementat în clasa KCurve Pătratul et este reprezentat în fundal, împărțit printr-o grilă în părți de-a lungul ambelor axe Dreptunghiul reprezintă căsuța de delimitare a glifului, în acest exemplu caracterul Punctele sunt indicate prin cercuri mici După cum puteți vedea din figură, punctele de pe linie alternează cu punctele de control Dar cel mai important lucru este că curbele construite corespund conturului definit de descrierea complexă a fontului Fonturi Tgyeture Orez Descrierea glifului ThieType Instrucțiuni pentru glif Privind listele și , s-ar putea să aveți impresia că rasterizatorul de fonturi ThieType este implementat cu ușurință prin transformarea căilor pentru glif - să zicem, prin completarea căii care este generată atunci când căile sunt redate cu funcția GDI StrokeFi AndPath Este puțin probabil ca un astfel de rasterizator de fonturi primitiv să aibă vreo utilizare practică, cu excepția dispozitivelor de înaltă rezoluție (cum ar fi imprimantele) Figura vă va ajuta să verificați acest lucru ABC ABC Orez Rasterizarea glifelor Figura compară două opțiuni pentru rasterizarea glifelor ThieType: cel mai simplu rasterizator din Listările și și rasterizatorul real Capitolul Fonturi glife pentru fonturile TrueType în sistemele de operare Microsoft Mai sus este rezultatul aplicării celui mai simplu rasterizator, iar mai jos este ceea ce implementează sistemul de operare Rezultatele sunt afișate atât la dimensiunea originală, cât și la mărire Partea dreaptă a figurii arată contururile glifului TrueType aproximate de ambele implementări După cum se poate observa din figură, cel mai simplu rasterizator creează imagini cu grosimi de linii diferite, pierderi de pixeli, pierderi de elemente de imagine, pierderi de simetrie etc Pe măsură ce dimensiunea scade, rezultatul devine și mai rău Scalarea unui contur glif definit pe un pătrat mare (de obicei de unități) la o grilă mai mică (să zicem x ) duce inevitabil la pierderea preciziei și a erorilor Să presupunem că două bare verticale sunt definite în unități em-pătrat cu casete de delimitare [ , , , ] și [ , , , ]; ambele caracteristici au aceeași dimensiune Sunt Totul arată grozav, dar să încercăm să reducem imaginea de ori cu rotunjire Prima liniuță este scalată la blocul [ , , , ], iar a doua este scalată la blocul [ , , , ] Rețineți că dimensiunile primei linii sunt acum x , iar dimensiunile celei de-a doua sunt acum x Așa apar liniile de diferite grosimi Uită-te la imagine - linia inferioară a literei B este mai groasă decât cea din mijloc și de sus TrueType rezolvă problemele de rasterizare controlând scalarea căii de la rețeaua pătrată em la rețeaua finală, astfel încât rezultatul să arate mai bine și să păstreze o asemănare cu designul glifului original Această tehnică, numită potrivire cu plasă, are trei obiective principale О Eliminați dependențele aleatorii de locația contururilor în grilă, astfel încât atunci când sunt rasterizate, aceeași grosime a liniei să fie menținută indiferent de locația lor în grilă О Păstrarea dimensiunilor cheie în cadrul aceluiași glif și între diferite glife О Păstrați simetria și alte aspecte importante ale glifei (cum ar fi serif-urile) Cerințele corespunzătoare pentru un font TrueType sunt codificate în două locuri: în tabelul cu valori de control și în instrucțiunile de adaptare la grilă specificate la nivel de glif individual Tabelul cu valori de control („cvt”) este conceput pentru a stoca o matrice ale cărei elemente pot fi utilizate în instrucțiuni De exemplu, pentru un font serif, parametrii care trebuie controlați ar putea fi înălțimea serifului, lățimea serifului, grosimea literelor majuscule și așa mai departe Aceste valori sunt introduse în tabelul cu valori de control într-o ordine cunoscută de designerul de fonturi și instrucțiunile ulterioare se referă la ele prin index În procesul de rasterizare a fonturilor, valorile tabelului de valori de control sunt scalate în funcție de dimensiunea curentă Utilizarea valorilor scalate în declarații asigură că aceleași valori sunt aplicate indiferent de poziția lor relativă în grilă De exemplu, dacă bara orizontală [ , , , ] este setată la [ , , +CVT[stem width], +CVT[stem height]] folosind două valori din tabelul CVT, atunci lățimea și înălțimea va rămâne constantă pentru orice poziție a liniei în grilă Cu fiecare definiție de glif este asociată o serie de instrucțiuni, numite instrucțiuni de glif, care controlează modul în care gliful se potrivește pe grilă Link-uri către pa Fonturi Opțiunile listei de verificare din instrucțiunile pentru glife asigură că aceste opțiuni vor fi valabile pentru toate glifele Instrucțiunile Glyph sunt pentru pseudomașina de stivă Mașina de stiva este utilizată pe scară largă în medii interpretate datorită simplității implementării sale În special, Forth (un limbaj simplu și puternic pentru sistemele încorporate), RPL (HP's Scientific Calculator Language) și Java Virtual Machine sunt construite pe mașinile stive O mașină de stivă de obicei nu are registre, deoarece toate calculele sunt efectuate pe stivă (unele mașini de stivă au o stivă de control separată de stiva de date) De exemplu, instrucțiunea PUSH împinge o valoare pe stivă, instrucțiunea POP îndepărtează elementul de sus din stivă, iar instrucțiunea de adăugare binară elimină primele două elemente din stivă și împinge suma lor pe stivă Mașina virtuală TrueType nu este o mașină de stivă de uz general Aceasta este o pseudo-mașină specializată, concepută cu scopul exclusiv de a potrivi contururile glifului la o grilă În plus față de valorile din tabelul cu valori de control, utilizează mai multe variabile de stare grafică (punctul de referință , punctul de referință , vector de proiecție etc ) Nu vom acoperi întregul set de instrucțiuni pentru glif TrueType În schimb, principiile de bază vor fi demonstrate cu un exemplu simplu de litere „H” din Tahoma Conturul glifului este prezentat în fig i ~P ; • ; : ■ riof- 'ii : : : : : : unu ' • ! • ; • : : : : : ; ; ; ; ; : ! ; ; ; : : l ::::::: ; • —! ! ! ! !!!!!!!!!! eu! '! ! ! :!!!!!!! • : : : : : • ! ! : ! :::::::: ! ! ::::::: L h J-J М ) Orez Contur al literei „H” a fontului Tahoma Litera H a lui Tahoma este compusă dintr-un singur contur cu puncte de control, toate situate pe o linie; cu alte cuvinte, nu există curbe Bezier în acest glif Pe lângă puncte, gliful conține de octeți de instrucțiuni, care ocupă mai mult spațiu decât coordonatele Mai jos este o listă de coordonate și instrucțiuni pentru glif Coordonatele : Despre : , Capitolul Fonturi : , : : , : , : , : , : , : , : , : , Lungimea instrucțiunii: : NPUSHB( ): : SRP : MIRPEsrp ,nmd,rd, ] : MIRPEsrpO md,rd, ] : SHP[rp ,zpl] : DELTAP : SRPO : MIRP[srpO,nmd,rd, ] : MIRPEsrpO md rd,l] : SHPErp ,zpl] : axa SVTCAEy] : MIAPErd+cl] : ALIGNRP : MIAPErd+ci] : ALIGNRP : SRP :IP : MDAPErd] : MIRPenrpO md rd l] : lUPEy] :lUPEx] Cei de octeți de instrucțiuni pentru glif sunt împărțiți în de instrucțiuni Majoritatea instrucțiunilor (cu excepția primei) constau dintr-un octet Fiecare instrucțiune are un nume mnemonic, un set de steaguri între paranteze drepte și o serie de parametri suplimentari Să parcurgem toate instrucțiunile unul câte unul Instrucțiunea NPIISHB (Push N bytes on the stack) împinge numărul specificat de octeți în stivă În acest exemplu, de octeți din fluxul de instrucțiuni sunt împinși în stivă Elementul superior al stivei este Instrucțiunea SRP (Set Reference Point ) scoate valoarea din stivă și setează punctul de referință ca punct de referință Punctul de referință corespunde punctului de referință et-square Instrucțiunea MIRP[srpO,nmd,rd, ] (deplasare relativă a punctului de referință) scoate valorile și din stivă și mută punctul astfel încât distanța sa față de punctul de referință să fie CVT[ ] (tabel intrare Fonturi valori de control cu indice ) Această instrucțiune ancorează punctul cel mai din stânga al glifului la distanța specificată de la punctul de bază pe axa x Instrucțiunea MIRP[srpO,md,rd,l] (deplasare relativă a punctului de referință) scoate valorile și din stivă și mută punctul față de punctul în funcție de valoarea CVT[ ] Acest lucru asigură o lățime fixă a barei orizontale Instrucțiunea SHP[rp ,zpl] (deplasare punct cu punct de referință) scoate valoarea din stivă și deplasează punctul cu aceeași distanță la care a fost deplasat punctul de referință (punctul ) Instrucțiunea DELTAP (excepția delta P ) scoate valorile , , , și din stivă și creează excepții cu valoarea la punctele și Ca urmare, punctele date sunt mutate cu suma determinată de valorile pereche ( ) În acest caz, numerele de puncte par să fie greșite Instrucțiunea SRPO (setare punct de referință ) scoate valoarea din stivă și setează punctul de referință ca punct de referință Punctul este un punct adăugat automat a cărui distanță de la punctul de bază al pătratului nash (punctul ) este egală cu lățimea completă a glifului Instrucțiunea MIRP[srpO,nmd,rd, ] (deplasare relativă a punctului de referință) scoate valorile și din stivă și mută punctul față de punctul cu offset CVT[ ] În plus, punctul de referință este mutat în punctul Instrucțiunea MIRP[srpO,nmd,rd, ] (deplasare relativă a punctului de referință) scoate valorile și din stivă și mută punctul în raport cu punctul cu offset CVT[ ] Instrucțiunea SHP[rp ,zpl] (deplasare punct cu punct de referință) scoate valoarea din stivă și deplasează punctul cu aceeași distanță la care a fost deplasat punctul de referință (punctul ) I Instrucțiunea SVTCA[axa y] mută vectorul de proiecție pe axa y Potrivirea axei x este făcută, trecem la axa y Instrucțiunea MIAP[rd+ci] scoate valorile și din stivă și mută punctul în poziția absolută CVT[ ] = Instrucțiunea ALIGNRP scoate valoarea din stivă și aliniază punctul cu punctul de referință (punctul ) Instrucțiunea MAIP[rd+ci] scoate valorile și din stivă și mută punctul în poziția absolută CVT[ ] = Acest lucru asigură că înălțimea literei H este determinată în mod unic Instrucțiunea ALIGNRP scoate valoarea din stivă și aliniază punctul cu punctul de referință (punctul ) Instrucțiunea SRP (Set Reference Point ) scoate valoarea din stivă și setează punctul de referință ca punct de referință Instrucțiunea IP (interpolare point) scoate valoarea din stivă și interpolează poziția punctului , având în vedere raportul inițial dintre punctele de referință ( și ) Capitolul Fonturi Instrucțiunea MDAP[rd] (punct de referință de mutare absolută) scoate valoarea din stivă, setează punctele de referință și la punctul și rotunjește punctul Instrucțiunea MIRP[nropO,md,rl,l] (deplasare relativă a punctului de referință) scoate valorile și din stivă și mută punctul față de punctul cu offset CVT[ ] Instrucțiunea IUP[y] interpolează restul punctelor de contur în direcția axei y Instrucțiunea IIIP[x] interpolează restul punctelor de contur în direcția x Cu toate acestea, aceasta este doar o descriere simplificată a instrucțiunilor pentru cel mai simplu glif Setul complet de instrucțiuni pentru glif ThieType și semantica lor este un subiect mult mai complex Există peste de instrucțiuni diferite, de variabile de stare grafică și mai multe tipuri de date Pentru detalii complete, consultați manualul de referință ThyeType la fonts apple com Metrici orizontale Informațiile stocate în tabelul de date cu glife sunt insuficiente pentru alinierea orizontală a unei secvențe de glife care formează o linie de text sau pentru alinierea verticală a liniilor unui paragraf Valorile de bază ale fonturilor latine ThyeType sunt stocate în două tabele: tabelul cu structură orizontală și tabelul cu metrici orizontale (tabelele „hhea” și „htmx”) Înainte de a lua în considerare aceste tabele, este necesar să vă familiarizați cu unele valori ale fonturilor prezentate în Fig Spațierea suprascriptelor (ascensiunea) este distanța de la marginea superioară a majusculelor până la linia de bază Spațierea în superscript este un atribut Fonturi volumul întregului font, nu un singur glif Această măsurătoare determină poziția liniei de bază a unui șir de text din poziția de început a ieșirii Spațierea subscriptelor (descent) este, de asemenea, un atribut de font și definește distanța de la linia de bază până la partea de jos a descendenților (în glife precum Q, q sau g) Suma spațierii subliniilor cu superscript este înălțimea liniei a fontului, deși se poate folosi spațiere suplimentară între rânduri la afișarea paragrafelor Fiecare glif are o casetă de delimitare, care în fonturile TrueType face parte din titlul glifului Caseta de delimitare este descrisă de quad [xmin,ymin,xmax,ymax], adică coordonatele minime și maxime ale punctelor de control al glifului Există de obicei un mic spațiu orizontal între punctul de bază și poziția xmin a glifului, care se numește umplutură din stânga După ce un glif este plasat pe o linie, punctul de bază al următorului glif este decalat față de poziția xmax cu o distanță numită indentare din dreapta Umplutura din stânga și din dreapta, ca și caseta de delimitare, sunt atribute ale glifelor individuale Suma umpluturii din stânga, a lățimii glifului (xmax - xtip) și a umpluturii din dreapta se numește lățimea totală Lățimea completă definește decalajul orizontal al punctului de bază după ce gliful a fost plasat pe linie Următorul glif este desenat din noul punct de bază Valorile de umplutură din stânga și din dreapta sunt de obicei pozitive, ceea ce înseamnă că glifele sunt separate prin spații suplimentare Cu toate acestea, uneori sunt negative pentru convergența glifelor De exemplu, în fontul Times New Roman, „j” minuscul are o indentație din stânga negativă, iar „f” minuscul are o indentație negativă la dreapta Pe fig Figura prezintă un „F” italic cu indentări negative pe ambele părți Orez Glif cu umplutură negativă la stânga și la dreapta În fonturile TrueType, atributele precum spațierea fonturilor pentru indicele și indicele sunt stocate într-un tabel de antet orizontal, iar datele la nivel de glif (cum ar fi umplutura din stânga și lățimea completă) sunt stocate într-un tabel cu valori orizontale Capitolul Fonturi Definiția structurii tabelului de antet orizontal ("hhea") este următoarea: typedef struct { versiune fixă; // x pentru versiunea FWord Ascender: // Spațiere tipografică în superscript FWord Descender; // Spațiere tipografică între rânduri FWord LineGap; // Spațiere tipografică între rânduri FWord advanceWidthMax; // Lățimea maximă completă FWord mlnLeftSideBearing: // Umplutură minimă din stânga FWord minRightSideBearing; // Umplutură la dreapta minimă FWord xMaxExtent; // Max (adăpare din stânga + (xMax - xMip)) SCURT caretSlopeRise: // Panta cursorului SCURT caretSlopeRun; // pentru poziția verticală SHORT rezervat[ ]: // Atribuit la SHORT metricDataFormat; // înseamnă formatul curent USHORT numberofHMetrics; // hElementele metrice din tabelul „htmx” } TablejdoriHeader; Tabelul de antet orizontal ("hhea") stochează spațierea superscriptului și a indicelui fontului, spațierea între rânduri, lățimea maximă completă, umplutura minimă la stânga și la dreapta, dimensiunile maxime (padding stânga + xmax - xmin), indicii de ieșire a căruciorului și informații despre orizontală tabelul de metrici Tabelul cu valori orizontale (tabelul „htmx”) stochează informații despre valorile orizontale la nivel de glif Pentru fiecare glif, trebuie să existe o modalitate de a obține umplutura din stânga și lățimea totală, din care umplutura din dreapta este calculată folosind formula „lățime completă - padding stânga - (xmax - xmin)" Cu toate acestea, pentru fonturile cu lățime fixă și lățime fixă, păstrarea mai multor copii ale lățimii întregi este considerată o risipă, așa că tabelul de valori orizontale este împărțit în două părți: prima parte stochează lățimea completă și umplutura din stânga a fiecărui glif, iar al doilea conține doar umplutura din stânga Tabelul ar trebui să conțină informații despre toate glifele din font; numărul de glife care au valori orizontale complete este stocat în ultimul câmp al tabelului antet orizontal (câmpul numberOfHMetrics) Mai jos este o descriere a structurii tabelului de valori orizontale Rețineți că ambele părți sunt matrice de lungime variabilă typedef struct { FWord advanceWidth; FWord Isb; }IngHorMetric; typedef struct { longHorMetric hMetrics[l]: // număr deHMetrics: FWord eftSideBearingEU: // Cu advanceWidth precedent } Table HoriMetrics; Datele de metrică orizontală font pot fi preluate folosind GDI utilizând funcțiile GetCharABCWidths, GetCharABCWidthsFloat și GetCharABCWidthsI În terminologia GDI, liniuța din stânga este numită metrica A, sunt numite xmax - xmin Fonturi Tgyeture este măsurată prin metrica B, iar indentarea dreaptă este metrica C Ne vom uita la aceste caracteristici în capitolul următor în introducerea noastră în formatarea textului, deoarece aceste caracteristici sunt mai mult legate de fonturile logice GDI decât de fonturile fizice ThieType kerning Când plasați glife într-o linie, opțiunile de umplutură din stânga și din dreapta sunt folosite pentru a-și îmbunătăți aspectul, dar pentru fiecare glif, aceste atribute sunt valori constante Când două glife particulare sunt adiacente, datorită formei lor, acele glife trebuie uneori să fie mai apropiate sau mai îndepărtate Ajustarea distanței dintre anumite perechi de glife se numește kerning Kerning face ca aceste combinații de glife să pară mai naturale În modul ThieType, datele de kerning sunt preluate dintr-un tabel creat de dezvoltatorul fontului Următoarele sunt structurile tabelului de kerning (tabelul „kern”) pentru fonturile ThieType typedef struct { FWord FWord FWord leftglyph; glif-dreapta: mutare; } KerningPair; typedef struct { FWordVersion; FWord nSubTables; FWord SubTableVersion; FWord Bytesinsubtable; Biți de acoperire FWord; FWord perechi de numere; FWordSearchRange; FWord EntrySelector; FWord RangeShift; KerningPair KerningPalr[l]: // Dimensiune variabilă } Table Kerning; Tabelul de kerning are o structură destul de simplă - constă dintr-un antet și o matrice simplă de structuri KerningPair; fiecare structură conține doi indici de glife și un amendament Perechile de kerning îi spun motorului de redare a textului să ajusteze distanța dintre două glife specifice în această ordine De exemplu, marginile primei perechi de kerning a fontului Tahoma sunt , , - Aceasta înseamnă: „Dacă gliful urmează imediat gliful , punctul său de bază este deplasat la stânga cu de unități pătrate shesh pentru a apropia glifele unul de celălalt ” Pentru un font care conține n glife, numărul maxim de perechi de kerning este n x n; dacă fontul este format din mii de glife, numărul este foarte mare Din fericire, dezvoltatorii de fonturi definesc doar perechi de kerning pentru referință Capitolul Fonturi doar un număr mic de cupluri De exemplu, fontul Tahoma are de perechi definite O aplicație poate obține date de kerning font folosind funcția GDI GetKerningPairs typedef struct { CUVÂNT wFIrstl WORD wAl doilea; int IKernAmount: } KERNINGPAIR: DWORD GetKerningPairs(HDC hDC DWORD nNumPairs LPKERNINGPAIR Ipkrnpair); Pentru a obține date de kerning pentru fontul logic curent selectat în contextul dispozitivului, apelați mai întâi funcția GetKerningPair cu parametrii (nNumPairs) și NULL (Ipkrnpair); funcția va returna numărul de perechi definite Alocați memorie și apelați din nou funcția pentru a obține datele reale de kerning Rețineți că valoarea iKernAmount din structura KERNINGPAIR este specificată în coordonatele logice ale contextului dispozitivului, nu în unitățile TrueType em-square Desigur, tabelul de kerning poate fi obținut și folosind funcția GetFontData OS/ și Windows Metrics Tabelul OS/ stochează date de metrică importante utilizate în sistemele de operare ale familiilor OS/ (IBM) și Windows (Microsoft) Numele sugerează că acest tabel a fost inițial destinat pentru OS/ Sistemul grafic trebuie să fie capabil să caracterizeze cumva diferitele fonturi instalate pe sistem, astfel încât, la cererea aplicației, să poată ridica fontul instalat care se potrivește cel mai bine cerințelor Tabelul OS/ conține un număr mare de atribute pe care sistemul grafic le ia în considerare la procesarea cererilor Tabelul OS/ are următoarea structură: typedef struct { versiunea USHORT; // x SHORT xAvgCharWidth; // Lățimea medie ponderată a z USHORT usWeightClass: // FWJHIN FW BLACK USHORT usWIdthClass: // ULTRA CONDENSED ULTRA EXPANDED SHORT fsType: // Posibilitatea de a încorpora fontul SCURT ySubscriptXSize: SCURT ySubscriptYSize: SHORT ySubscriptXOffset: SHORT ySubscriptYOffset; SCURT ySuperscriptXSize; SCURT ySuperscriptYSize; SCURT ySuperscriptXOffset: SCURT ySuperscriptYOffset; SHORT yStri keoutSize: // Grosimea liniei de lovire SCURT yPoziție Strikeout: SCURT sFamilyClass: // Fonturi IBM Fonturi PANOSE panose; ULONG ulUnicodeRangel; // Biți - Interval de caractere Unicode ULONG ulUnicodeRange ; // Biții - ULONG ulUnicodeRange ; // Biții - ULONG ulUnicodeRange ; // Biții - CHAR achVendID[ ]; // ID furnizor USHORT fsSelection; //ITALIC REGULAR USHORT usFirstCharlndex; // Primul caracter UNICODE USHORT usLastCharIndex: // Ultimul caracter UNICODE USHORT sTypoAscender; // Spațiere tipografică în superscript USHORT sTypoDescender: // Spațiere tipografică sublinie USHORT sTypoLineGap; // Spațiere tipografică între rânduri USHORT usWinAscent; // Spațiere superlinie pentru Windows USHORT usWinDescent; // Spațiere sublinie pentru Windows ULONG ulCodePageRangel: // Biți - ULONG ulCodePageRange ; // Biții - } Tabel S ; Tabelul „OS/ ” conține informații detaliate într-un format suficient de apropiat de structurile de valori ale fonturilor GDI, cum ar fi LOGFONT, TEXTMETRICS, ENUMTEXTMETRIC și OUTLINETEXTMETRIC Datorită naturii multi-platformă a fonturilor TrueType, abundența de informații inconsistente poate fi uneori confuză De exemplu, tabelul OS/ stochează două seturi de spațiere pentru indice și indice, care nu se potrivesc întotdeauna cu atributele cu același nume stocate în tabelul antet orizontal Alte mese Am acoperit în detaliu cele mai importante tabele de fonturi TrueType Cu toate acestea, fonturile TrueType/OpenType pot conține și alte tabele legate de caracteristici non-triviale utilizate pe alte platforme sau pur și simplu atunci când imprimați pe o imprimantă Un tabel de nume ("pate") permite ca datele șirurilor în mai multe limbi să fie asociate cu un font TrueType Șirurile pot conține nume de fonturi, familii, stiluri, informații despre drepturile de autor etc Tabelul PostScript ("post") conține informații suplimentare pentru imprimantele PostScript, inclusiv o descriere a FontInfo și numele PostScript ale tuturor pictogramelor de font Tabelul de „pregătire” al programului conține instrucțiuni TrueType care trebuie executate ori de câte ori fontul, dimensiunea sau matricea de transformare este schimbată, înainte ca conturul glifului să fie interpretat Tabelul programului de fonturi ("fpgm") conține instrucțiuni care sunt executate atunci când fontul este utilizat pentru prima dată Tabelul de bază ("BASE") conține informații utilizate pentru a alinia glife de diferite stiluri și dimensiuni pe aceeași linie Un tabel de definire a glifurilor („GDEF”) conține date de clasificare a glifurilor, puncte de intrare pentru accesul mai ușor la date și stocarea în cache raster etc Un tabel de plasare a glifurilor („GPOS”) permite un control fin al pozițiilor glifurilor pentru formatarea textului netrivială în fiecare față și limbă, susținută de font Tabel de înlocuire a glifelor Capitolul Fonturi ("GSUB") conține informații de înlocuire a glifurilor pentru a reproduce stilurile și limbile acceptate Este folosit pentru a susține ligaturi, înlocuirea glifelor la locul său și așa mai departe Tabelul de justificare ("JSFT") oferă un control suplimentar asupra înlocuirii și poziționării glifelor în text justificat Tabelul de antet vertical ("vhea") și tabelul de valori verticale ("vmtx") conțin date de valori pentru fonturile verticale, inclusiv copii în oglindă ale tabelului de antet orizontal și ale tabelelor de valori orizontale Tabelul de semnături electronice („DSIG”) conține semnătura electronică a fontului OpenType, pe baza căreia sunt implementate unele măsuri de securitate De exemplu, cu o semnătură electronică, sistemul de operare poate verifica sursa și integritatea fișierelor cu fonturi înainte de a fi utilizate, iar un dezvoltator de fonturi poate stabili restricții privind încorporarea fonturilor în documente Colecțiile TgieTure Tehnologia Microsoft OpenType permite ca mai multe fonturi OpenType să fie împachetate într-un singur fișier de font numit „ThieType Collection” (Colecția TTC) Colecțiile ThieType sunt utile pentru a trata fonturi similare care au un număr mare de aceleași glife De exemplu, setul de caractere japoneze este împărțit într-un număr mic de glife kana (silabar japonez) și mii de glife kanji (kanji) În grupul de fonturi japoneze, ar fi perfect logic să definiți glife kana unice atunci când utilizați glife kanji obișnuite După cum am menționat mai sus, un font TrueType/OpenType normal constă dintr-un director și mai multe tabele Un fișier de colecție ThieType constă dintr-un tabel antet TTC, mai multe directoare de tabel (câte unul pentru fiecare font) și un număr mare de tabele (utilizate împreună sau separat) Tabelul antet TTS este destul de simplu Stochează eticheta ("ttcf"), versiunea, numărul de directoare și o serie de decalaje de director pentru tabelele TgyeType typedef struct ULONGTTCTag; // Eticheta TTC „ttcf” Versiune ULONG: // Versiune TTC (inițial x ) ULONG DirectoryCount; // Numărul de directoare de tabel directorul DWORD[l]; // Decalaje director (dimensiune variabilă) }TTC Header: Deși colecțiile de fonturi economisesc memorie și spațiu pe disc, ele distrug funcția GetFontData Când este apelată GetFontData, aplicația solicită date ThieType pentru întreg fontul, le salvează și le transferă pe alt computer unde fontul este instalat ulterior Cu toate acestea, atunci când lucrează cu colecția, aplicația nu știe dacă datele primite sunt complete sau dacă fac parte din colecția de fonturi ThieType Și mai rău, sunt date unele compensații Instalarea și încorporarea fonturilor relativ la antetul invizibil al colecției TrueType în loc de directorul tabelului curent De exemplu, offset-urile din structura TableDirectory sunt relative la începutul fișierului fizic, deci depind de faptul dacă datele provin dintr-un singur font sau dintr-o colecție Soluția este să verificați dimensiunile tuturor fonturilor din colecție cu eticheta TTS Comparându-le cu dimensiunile fontului curent, puteți determina offset-ul acestuia în colecție și apoi îl puteți utiliza pentru a găsi tabelele de care aveți nevoie Instalarea și încorporarea fonturilor Fonturile sunt distribuite ca fișiere Pentru ca un font să fie folosit de aplicații, acesta trebuie să fie preinstalat de sistemul de operare Există mai multe funcții în GDI care controlează instalarea și eliminarea fonturilor și sunt folosite la încorporarea fonturilor în aplicații sau documente BOOL CreateScalableFontResource(DWORD fdwHidden, LPCTSTR IpszFontRes, LPCTSTR IpszFontFile, LPCTSTR IpszCurrentPath): Int AddFontResource(LPCTSTR IpszFIleName): BOOL RemoveFontResource(LPCTSTR IpFileName): int AddFontResourceEx(LPCTSTR IpszFIleName, DWORD f , DESIGNVECTOR*pdv): int RemoveFontResourceEx(LPCTSTR IpszFIleName, DWORD f , DESIGNVECTOR * pdv): HANDLE AddFontMemResourceEx(LPVOID pbFont, DWORD cbFont DESIGNVECTOR * pdb, DWORD * pcFonts): int RemoveFontMemResourceEx(HANDLE fh): Fișiere cu resurse de font Fonturile vectoriale și bitmap au fost considerate principalele tipuri de fonturi în sistemele de operare Windows, în timp ce formatele TrueType, OpenType și PostScript au fost percepute inițial ca ceva străin Mai multe resurse de fonturi bitmap sau vector (de obicei, cu același tip de caractere, dar cu dimensiuni diferite) au fost grupate în DLL-uri pe biți numite fișiere cu resurse de font În aceste fișiere, fonturile au fost conectate la aplicație ca resurse binare de tip FONT (RT FONT) Suportul de instalare directă a fonturilor este oferit în GDI numai pentru fonturile în vechiul format de fișier cu resurse de font pe biți Pentru a instala un font TrueType, trebuie să creați un fișier resursă de font scalabil Fișierul cu resursă de font scalabil are același format DLL pe biți, dar nu conține o copie a fontului TrueType În schimb, specifică numele fișierului font TrueType prin care GDI găsește datele fontului Pentru a crea un fișier cu resursă de font scalabil, apelați funcția CreateScalableFontResource și transmiteți-o Capitolul Fonturi un indicator întreg, numele fișierului de resurse care urmează să fie creat, numele unui fișier de font ThieType existent și calea către acesta (dacă nu este inclusă în nume) Indicatorul fdwHidden îi spune GDI dacă fontul ar trebui să fie ascuns de alte procese din sistem Funcția CreateScalableFontResource scrie un fișier resursă font mic pe disc Se recomandă ca fișierele cu resurse de font ThieType să aibă extensia FOT pentru a face diferența între resursele de font bitmap și vector cu extensii FON Instalarea fonturilor deschise Funcția AddFontResource instalează un font pe sistem cu numele unui fișier resursă, care poate fi un font bitmap, vector sau ThieType Ca urmare a instalării fonturilor, fișierul de resurse este introdus în tabelul de fonturi de sistem și începe să fie utilizat la enumerarea fonturilor, înlocuirea fonturilor, crearea fonturilor logice și afișarea textului Fontul setat de funcția AddFontResource este disponibil pentru toate aplicațiile, cu excepția cazului în care resursa de font a fost creată cu un steag special pentru a o ascunde în timpul procesului de enumerare a fonturilor Cu toate acestea, fontul setat de funcția AddFontResource este disponibil numai în timpul sesiunii curente După o repornire, fontul nu va fi adăugat automat la tabelul cu fonturi Pentru ca fontul instalat să fie permanent prezent în sistem, informațiile despre acesta trebuie incluse în registru Funcția RemoveFontResource face opusul - elimină o resursă de font din tabelul de sistem În același timp, aplicațiile care rulează trebuie să fie notificate cu privire la modificările din tabelul fonturilor sistemului O aplicație care modifică tabelul de fonturi trebuie să notifice toate ferestrele de nivel superior trimițând un mesaj WM FONTCHANGE O aplicație care utilizează o listă de fonturi instalate trebuie să proceseze mesajul WM FONTCHANGE și să actualizeze conținutul listei Instalarea fonturilor și fonturilor proprietare Multiple Mașter OrepTure Windows a introdus noile funcții AddFontresourceEx și RemoveFontRe-sourceEx Al doilea parametru, AddFontResourceEx, controlează dacă fontul este „închis” Când bitul FP PRIVATE este setat, fontul nu poate fi folosit de alte procese și devine indisponibil după terminarea procesului curent; dacă este setat indicatorul FP NOT ENUM, fontul nu participă la enumerare Setând oricare dintre aceste semnalizatoare, nu mai trebuie să difuzați un mesaj WM FONTCHANGE și să notificați altor aplicații un font cu care nu pot lucra Funcția RemoveFontResourceEx folosește același parametru ca AddFontResour-ceEx pentru a elimina fontul setat de funcția AddFontResourceEx Ultimul parametru este un pointer către o structură DESIGNVECTOR folosită numai pentru fonturi Multiple Mașter OpenType Mai multe fonturi Mașter OpenType se bazează pe tehnologia de fonturi PostScript Type Instalarea și încorporarea fonturilor sunt numite axe), ceea ce permite ajustarea fină a aspectului unui font De exemplu, axa de greutate a fontului Multiple Mașter OpenType poate varia de la (subțire) la (greu) Structura DESIGNVECTOR are o dimensiune variabilă și conține informații despre numărul de caracteristici și valorile acestora Instalarea fonturilor dintr-o imagine de memorie Pentru a instala un font TrueType utilizând funcția AddFontResource sau AddFontResourceEx, două fișiere fizice trebuie să fie pe disc, un fișier cu font TrueType și un fișier cu resurse de font Acest lucru face dificilă programarea aplicațiilor care funcționează cu fonturi proprietare și masca complet fonturile proprietare din alte aplicații Funcția AddFontMemResourceEx, introdusă în Windows , încearcă să rezolve aceste probleme permițând instalarea fonturilor dintr-o imagine din memorie Primii doi parametri ai acestei funcții specifică adresa și dimensiunea unui bloc de memorie care conține una sau mai multe resurse de font Al treilea parametru conține un pointer către o structură DESIGNVECTOR pentru fonturi Multiple Mașter OpenType Funcția AddFontMemresource instalează fonturi dintr-o imagine din memorie, returnând un handle și numărul de fonturi instalate Fonturile instalate de funcția AddFontResourceEx rămân întotdeauna private pentru aplicația în care a fost apelată funcția Aplicația poate elimina apoi fonturile cu funcția RemoveFontMemResourceEx, trecându-i mânerul rezultat Dacă aplicația nu face acest lucru, fonturile vor fi eliminate automat când procesul se termină Blocul de memorie transmis funcției AddFontMemResource este completat în formatul de date brute de resurse, nu în formatul DLL a resursei de font pe biți În comparație cu funcțiile AddFontResource și AddFontResourceEx, funcția AddFontMemResourceEx este mult mai convenabilă deoarece permite unei aplicații să instaleze și să utilizeze fonturi independent de alte aplicații Încorporarea fonturilor Probleme serioase cu fonturile apar adesea la transferul documentelor pe alte computere Instalând fonturile dorite pe computer, puteți formata documentul și îi puteți da aspectul dorit Dar dacă deschideți acest document pe un alt computer cu un set diferit de fonturi instalat, poate arăta complet diferit Probleme similare apar în aplicațiile care folosesc fonturi specializate, atunci când lucrează cu documente de procesor de text, pagini web și chiar fișiere spooler atunci când se imprimă pe un server la distanță Tehnologia de încorporare a fonturilor vă permite să includeți fonturi speciale direct în document Fonturile încorporate sunt instalate automat pe celălalt computer atunci când deschideți un document, astfel încât documentul își păstrează aspectul original Încorporarea fonturilor trebuie să respecte regulile de licențiere pentru utilizarea fonturilor Există șase niveluri definite pentru fonturile TrueType/OpenType Capitolul Fonturi încorporarea acestuia, indicată de indicatorul fsType în tabelul de valori OS/ și Windows ("OS/ ") O încorporare instalabilă ( x ): fontul poate fi încorporat în documente și instalat pe un sistem la distanță pentru utilizare permanentă Majoritatea fonturilor livrate cu sistemul de operare Windows permit exact această metodă de încorporare A Embed pentru editare ( x ): Fontul poate fi încorporat în documente, dar numai pentru instalare temporară pe un sistem la distanță De exemplu, dacă încorporați un astfel de font într-un document Word, puteți vizualiza și edita documentul pe un computer la distanță, dar când ieșiți din WinWord, fontul este șters automat din sistem A View Embedding ( x ), cunoscută și sub numele de Read-Only Embedding: un font poate fi încorporat în documente, dar numai pentru instalare temporară pe un sistem la distanță Documentele pot fi deschise doar pentru citire Datele fontului trebuie să fie criptate în document Pe computerul de la distanță, fontul este decodat într-un fișier ascuns fără extensia TTF, instalat ca font ascuns, folosit doar pentru vizualizarea și imprimarea documentului și șters la ieșirea aplicației A Dezactivați încorporarea parțială ( x ): permite numai încorporarea completă a întregului font O încorporare bitmap ( x ): încorporarea este permisă numai pentru bitmap-urile conținute în font Dacă un font este format din toate contururile glifului, acesta nu poate fi încorporat A Deny Embedding ( x ): fontul nu poate fi încorporat în documente Rețineți că nivelul de încorporare a fonturilor se aplică numai încorporarii fontului în documente, nu și în aplicații Potrivit MSDN, fonturile nu pot fi încorporate în aplicații, iar aplicațiile nu pot fi livrate cu documente care conțin fonturi încorporate Funcția GetOutlineTextMetrics este utilizată pentru a verifica capacitatea de încorporare a fonturilor TrueType/OpenType Returnează o structură OUTLINETEXTMETRIC al cărei conținut este apropiat de cel al tabelului de metrice OS/ și Windows (tabelul „OS/ ”) într-un fișier cu font TrueType Câmpul otmfsType al acestei structuri are aceeași semnificație ca și câmpul fsType descris mai sus Lista prezintă două funcții pentru instalarea și eliminarea fonturilor TrueType/OpenType Funcția Instal IFont primește imaginea fontului TrueType/OpenType în memorie, creează fișiere TTF și FOT și instalează fontul Funcția RemoveFont elimină un font din lista de sistem și elimină fișierele TTF și FOT Ambele funcții primesc un parametru de opțiune care spune dacă fontul ar trebui să fie public, ascuns, privat, nenumerabil sau setat direct dintr-o imagine din memorie În funcție de valoarea opțiunii, este selectată funcția GDI care este apelată la instalarea și eliminarea fontului Lista Instalarea și eliminarea fonturilor #define FR HIDDEN x #define FR MEM x Instalarea și încorporarea fonturilor BOOL RemoveFont(const TCHAR * fontname int opțiune, HANDLE hFont) { if ( opțiune & FR MEM ) { return RemoveFontMemResourceEx(hFont); } TCHAR ttffile[MAX PATH]; TCHAR fotfile[MAX PATH]; GetCurrentDirectory(MAX PATH-l, ttffile): tcscpy(fotfile, ttffle); wsprintf(ttfflle + tcslen(ttfflle), "WXs ttf", fontname); wsprintf(fotfile + tcslen(fotfile), "WXs fot", fontname); BOOL rslt; comutator (opțiune) { cazul ; caz FR HIDDEN; rslt = RemoveFontResource(fotfile); pauză; caz FR-PRIVAT: cazul FR NOT ENUM: caz FR PRIVATE | FR NOT ENUM: rslt = RemoveFontResourceEx(fotfile, option, NULL): break; Mod implicit: afirmă (fals); rslt=FALSE; } dacă ( ! DeleteFile(fotfile) ) rslt=FALSE; dacă ( ! DeleteFi e(ttffi e) ) rslt=FALSE; return rslt; } HANDLE InstallFont(void * fontdata, unsigned fontsize, const TCHAR * fontname, opțiune int) { if ( opțiune & FR MEM ) { număr DWORD; returnează AddFontMemResourceEx(datele fontului, dimensiunea fontului, NULL și num); } TCHAR ttffile[MAX PATH]; Continuare Capitolul Fonturi Lista Continuare TCHAR fotfile[MAX PATH]; GetCurrentDirectory(MAX PATH-l, ttffile); tcscpy(fotfile, ttfffile); wsprintf(ttffile + tcslen(ttffile) „\Us ttf”, fontname); wsprintf(fotfile + tcslen(fotfile), „\Us fot”, fontname); HANDLE hFile = CreateFile(ttffile, GENERIC WRITE, NULL, CREATE ALWAYS, FILE ATTRIBUTE NORMAL | FILE FLAG SEQUENTIAL SCAN, ); if ( hFile==INVALID HANDLE VALUE ) returnează NULL; DWORD dwScris; WriteFi e(hFi e, fontdata, fontsize și dwWritten, NULL); FIushFi eBuffers(hFi e); CloseHandle(hFile); if (! CreateScalableFontResource(opțiune & FRJHIDDEN fotfile, ttffile, NULL) ) returnează NULL; comutator (opțiune) { cazul ; carcasa FR-HIDDEN; return (HANDLE) AddFontResource(fotfile); caz FR PRIVATE; cazul FR NOT ENUM: caz FR PRIVATE | FR NOT ENUM: returnează (HANDLE) AddFontResourceEx(fotfile, opțiune, NULL); Mod implicit: afirmă (fals); returnează NULL; } } Funcțiile prezentate în Lista - au fost folosite într-un program demo simplu FontEmbed Acest program este o aplicație simplă cu casetă de dialog (Figura - ) Există trei butoane în caseta de dialog FontEmbed Butonul Generare generează un „document” cu fonturi TrueType/OpenType încorporate selectate de utilizator, folosind un mecanism simplu de criptare Butonul Încărcare încarcă documentul generat și instalează fonturile încorporate în sistem Modul de utilizare a fontului este determinat de un grup de butoane radio Butonul Descărcare elimină toate resursele de font instalate În dreapta sunt rezultatele obținute atunci când textul este afișat în fonturi încorporate Instalarea și încorporarea fonturilor Font Generare încărcare | Urioad | Ascuns ~ * Privat OzSEtC Black Nu Enumera ef fe ■ Memorie BiMCfl ЛІ С Orez Demo de încorporare a fonturilor Trei fonturi TrueType gratuite de pe pagina web HP FontSmart Homage (www fonstmart com) au fost folosite la construirea desenului: Euro Sign, Ozzie Black și Ozzie Black Italic Dacă aceste fonturi nu sunt instalate în sistem, prima linie este afișată în fontul standard Symbol, iar celelalte două în fontul Agria După instalarea fonturilor, caseta de dialog arată ca cea prezentată în figură, dar după ștergerea fonturilor, fereastra revine la forma anterioară Dacă nu aveți aceste fonturi, descărcați-le și, dacă aveți, căutați online câteva fonturi noi gratuite sau shareware Lansați programul FontEmbed, experimentați cu diferite opțiuni de instalare și verificați dacă fontul este disponibil după instalare în aplicația curentă și în alte aplicații Tabel cu fonturi de sistem Pe Windows NT/ , lista fonturilor prezente permanent pe sistem este stocată în următoarea cheie de registry: HKEY LOCAL MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts În timpul pornirii sistemului, fonturile sunt încărcate în tabelul de fonturi ale sistemului, făcându-le disponibile pentru utilizare Fonturile din listă corespund fonturilor fizice partajate de toate procesele din sistem De fapt, motorul grafic stochează până la trei tabele în spațiul de adrese în modul kernel - pentru fonturile deschise, pentru fonturile private și pentru fonturile de dispozitiv care sunt de obicei acceptate de imprimantele moderne (de exemplu, imprimantele PostScript) Fonturile persistente furnizate de sistemul de operare trebuie de obicei să fie disponibile pentru toate aplicațiile, astfel încât acestea sunt stocate în tabelul public de fonturi Dacă un fișier resursă de font OpenType/ThieType este creat cu indicatorul de ascundere, trecerea steagului FR HIDDEN la apelarea CreateFontResourceEx sau la utilizarea funcției CreateFontMemResourceEx stochează fontul într-un tabel privat de fonturi Dacă indicatorul FR NOT ENUM este utilizat fără steagul FR HIDDEN, fontul este tabelat Capitolul Fonturi face fonturi deschise Lista de fonturi de sistem stochează căile complete către fișierele fiecărui font Dacă fontul a fost instalat dintr-o resursă din memorie, pentru acesta este folosit pseudo-numele de fișier de tip „MEMORY- ” Extensia de depanare GDI acceptă trei comenzi pubft, pvtft și devft pentru a afișa conținutul tabelelor cu fonturi Puteți utiliza aceste comenzi în programul de control Fosterer (vezi Capitolul ) Rezultate Acest capitol este dedicat principiilor de bază ale textului în programarea grafică Windows Începe cu o descriere a conceptelor de bază ale fonturilor: caractere, seturi de caractere, glife, codificări și maparea caracterelor la glife Următoarele descriu cele trei tipuri principale de fonturi Windows: fonturi bitmap, vector și ThieType Ne facem cunoștință cu modul în care sunt reprezentate glifele în fiecare tip de font și cu modul în care sunt afișate în timpul procesului de rasterizare Capitolul se încheie cu o descriere a modului de instalare și dezinstalare a fonturilor și a modului de încorporare a fonturilor în documente Având o bună înțelegere a fonturilor încorporată în acest capitol, în Capitolul trecem la o utilizare practică a acestora - ieșirea textului Exemple de programe Capitolul este însoțit de două exemple de programe (Tabelul ) Tabelul Capitolul Programe Descriere director de proiect Samples\Cap \Fonts caractere, codificări, glife, familii de fonturi, procesul de enumerare și cele trei tipuri principale de fonturi (bitmap, vector și fonturi ThieType) Samples\Chapt \FontEmbed O ilustrare a instalării, eliminării și încorporarii fonturilor în documente Capitolul Text După cum sa arătat în capitolul anterior, fonturile sunt elementul principal al textului de ieșire Acest capitol acoperă fonturile logice, funcțiile de ieșire a textului, formatarea de bază, formatarea fină și precisă și efectele speciale utilizate în ieșirea textului Fonturi logice Capitolul a acoperit caracteristicile cheie ale celor trei tehnologii de fonturi principale utilizate în programarea Windows - fonturi raster, fonturi vectoriale și fonturi TrueType/OpenType Cu toate acestea, chiar dacă sunteți bine versat în structura fonturilor fizice, lucrul direct cu ele este o sarcină complexă și consumatoare de timp, care în mod clar nu merită să piardă timpul unui programator Din fericire, atunci când afișează text, aplicațiile Windows (și chiar motorul grafic) nu trebuie să vorbească direct cu fonturile fizice Un program de aplicație funcționează de obicei numai cu fonturi logice folosind funcții speciale API Fonturile fizice sunt gestionate de drivere de font care sunt la același nivel cu driverele de dispozitiv grafic din sistem Motorul grafic Windows NT/ oferă trei drivere de fonturi pentru trei tipuri de fonturi acceptate direct de Microsoft Fonturile ATM sunt acceptate de un driver de font separat (atmfd dll) Suportul pentru fonturile logice se bazează pe interacțiunea motorului grafic cu driverele de font În comparație cu fonturile fizice, fonturile logice au o serie de avantaje semnificative A Fonturile logice asigură independența dispozitivului Un font logic este creat dintr-o listă de cerințe de utilizator pentru un font Motorul grafic este responsabil pentru selectarea unui font cu parametrii specificați dintre fonturile fizice instalate pe sistem Sistemul va putea selecta Capitolul font similar chiar dacă unele fonturi lipsesc În același timp, pot fi selectate diferite fonturi pentru diferite dispozitive grafice care îndeplinesc cerințele specificate A Fonturile logice acceptă utilizarea codificărilor Pentru a găsi un glif pentru o anumită codificare în fontul ThyeType, va trebui să căutați în tabelul de mapare a caracterelor indicii de glif Fonturile booleene maschează indexurile glifelor din aplicații Fonturile booleene vă permit să instanțiați fonturi cu dimensiuni specificate Descrierile glifelor dintr-un font sunt șabloane generice pentru construirea de glife cu orice dimensiune a punctului sau unghi de rotație Un font bitmap conține de obicei diferite resurse de font pentru diferite dimensiuni Fonturile vectoriale și fonturile ThyeType/OrepType permit scalarea arbitrară și orice transformări Când selectați un font logic în contextul dispozitivului, este creată o anumită instanță de font cu dimensiunea punctului și unghiul de rotație specificate Această arhitectură permite motorului grafic și driverelor de font să memoreze în cache versiuni scalate și rasterizate ale glifelor pentru a îmbunătăți performanța sistemului Fonturile booleene vă permit să simulați anumite caracteristici în software Unele stiluri de font obișnuite (cum ar fi sublinierea și barajul) nu sunt implementate în fonturile fizice, ci sunt simulate de GDI În plus, GDI poate simula cursive și aldine în cazurile în care fontul fizic adecvat nu este disponibil Valorile fonturilor Windows Înainte de a intra în detaliile fonturilor logice, să aruncăm o privire la termenii folosiți atunci când lucrați cu fonturi în Windows Rețineți că sensul unor termeni GDI Windows este ușor diferit de sensul acelor termeni din specificația fontului ThieType și tipografia tradițională Pe fig Figura prezintă principalele valori utilizate la formatarea textului în GDI Linia imaginară de-a lungul căreia gliful este aliniat vertical se numește linia de bază Cel mai jos punct al majorității majusculelor este aproape pe linia de bază Simbolurile sunt situate în celule de aceeași înălțime Distanța de la marginea superioară a celulei la linia de bază se numește spațiere în superscript În mod obișnuit, nici cele mai înalte glife nu ajung în partea de sus a celulei, așa că conceptul GDI de „spațiere pentru superscript” este oarecum diferit de spațierea tipografică pentru superscript utilizat în fonturile ThieType Distanța de la linia de bază până la partea de jos a celulei de caractere se numește spațiere indice Punctul de jos al unui descendent de glif poate fi, de asemenea, separat la o anumită distanță de partea inferioară a celulei Suma spațierii indicelui și indicelui se numește înălțimea fontului Spațiul dintre superscript și partea de sus a celulei este de obicei umplut cu accente și alte semne diacritice Înălțimea acestui bal Fonturi logice straniul se numește decalaj intern (internai lead) Când mai multe linii de text formează un paragraf, partea de jos a celulelor liniei anterioare este separată de partea superioară a celulelor liniei curente printr-o spațiere suplimentară numită decalaj extern (externai lead) Dimensiunea textului este măsurată în puncte În tipărirea tradițională, un punct este egal cu , inchi ( / , inchi) În aspectul computerului, un punct este rotunjit la / de inch, astfel încât un inch este format din exact de puncte Eroarea este de doar / de inch, deci din motive practice poate fi neglijată Când se face referire la text sau font, termenul „dimensiune” se referă la metrica „spațiere superlinie + spațiere indice - spațiere internă”, adică „înălțime - spațiere internă” Vă rugăm să rețineți: știftul nu include niciun spațiu liber intern sau extern De exemplu, într-un paragraf cu text de puncte, suma „spațiere superlinie + spațiere indice - spațiere internă” este de puncte, ceea ce corespunde la , pixeli pe un ecran de dpi sau , pixeli pe o imprimantă de dpi În paragrafele cu puncte, distanța dintre linii este de obicei de sau puncte, adică sau , linii pe inch Valorile orizontale utilizate în GDI sunt aproape identice cu valorile fonturilor TrueType Distanța dintre două caractere adiacente se numește lățime completă Lățimea completă este împărțită în trei părți Partea din stânga corespunde de obicei spațiului dinaintea punctului cel mai din stânga al glifului; aceasta se numește metrica A (liniuță din stânga în terminologia fontului TrueType) Partea din mijloc definește lățimea reală a glifului din celulă și se numește metrica B Partea din dreapta corespunde de obicei spațiului de după punctul cel mai din dreapta al glifului și se numește metrica C (indentarea din dreapta în TrueType) Lățimea completă a unui caracter este egală cu suma valorilor A, B și C Valorile A și C pot avea valori negative pentru convergența glifului, în special în fonturile italice Capitolul Fonturi standard Un font logic este un obiect GDI care descrie cerințele pentru o anumită implementare a unui font fizic Obiectul font logic, ca și alte obiecte GDI, este gestionat de GDI și este o cutie neagră din punctul de vedere al aplicației Aplicațiile utilizator funcționează cu fonturi logice numai prin manipulatoare de fonturi logice de tip HFONT Sistemul definește șapte fonturi logice GDI standard (încorporate) care sunt utilizate de sistemul de operare atunci când se afișează interfața cu utilizatorul, precum și în aplicații Manipulatoarele standard de fonturi booleene sunt returnate prin apeluri la GetStockObject (FONT DEFAULT GUI), GetStockObject (SYSTEMFONT) și așa mai departe arată fonturi standard pe un monitor de dpi Pentru fiecare font standard, se oferă o metodă de obținere a unui manipulator folosind funcția GetStockObject și conținutul structurii LOGFONT, care va fi discutat mai jos DialogBaseUnits: baseunixX= , baseunitY= GetDeviceCaps(LOGPIXELSX)= , GetDeviceCaps(LOGPIXELSX)= GetStockObject(DEFAULT GULFONT) {- , , , , , , , , , , , , , MS Shell Dig} GetStockObject GetStockObject(ÂNSI FIXED FONT) { , , , , , , , , , , , , , Courier} GetStockObiect(ANSI VAR FONT) { , , , , , , , , , , , , , MS Sans Șerif} GetStockObject(SYSTEMFONȚ) { , , , , , , , , , , , , , System} , , , , , System} GetStockObject(SVSTEM FIXED FONT) { , , , , , O, O, O, O, , , , , Fixedsys} Orez Fonturi standard la dpi Fonturile standard se găsesc adesea în titlurile ferestrelor, meniuri și text afișate în diferite comenzi Dimensiunea standard a fontului în pixeli se modifică atunci când rezoluția logică a ecranului se modifică De exemplu, rezoluția logică a unui ecran normal este de dpi - așa-numitul mod „fonturi mici” Folosind panoul de control, puteți trece la modul „fonturi mari” cu o rezoluție de dpi Când treceți ecranul de la modul font mic la modul font mare, toate fonturile standard trebuie remapate la fonturi fizice mai mari Fonturi logice o măsură pentru care de obicei se repornește sistemul După aceea, toate titlurile ferestrelor, meniurile, elementele și casetele de dialog cresc în funcție de modificările dimensiunii fontului Proiectarea unei interfețe de utilizator care să arate perfect în ambele moduri (fonturi mari și mici) nu este o sarcină ușoară Puteți utiliza funcția GetSystemMetrics pentru a obține diferite valori de sistem, inclusiv dimensiunile curente ale barelor de titlu și de meniu De exemplu, un apel la GetSystemMetrics(SM CYMENU) returnează înălțimea unei bare de meniu cu o singură linie de comandă Casetele de dialog sunt proiectate în unități de dialog șablon independente de dispozitiv La crearea unei casete de dialog, unitățile de șablon sunt convertite în pixeli de ecran, ținând cont de unitățile de dialog de bază curente, folosind următoarele formule: pixelX = (templateunitX * baseunitX) / ; pixelY = (templateunity * baseunltY) / : Unitățile de dialog de bază sunt definite de lățimea și înălțimea medie a caracterelor ale fontului standard utilizat pentru afișarea elementelor în casetele de dialog Valorile acestora pot fi obținute folosind funcția GetDialogBaseUnits La dpi, baseunitX = și baseunltY = , astfel încât fiecare unitate de dialog șablon este convertită în doi pixeli de ecran La dpi, baseunitX = , baseunitY = și fiecare unitate de dialog șablon este convertită la , pixeli de ecran Ca rezultat, la trecerea de la modul font mic la modul font mare, casetele de dialog sunt mărite cu , % La prima vedere, totul pare a fi foarte cool, deoarece obțineți text de înaltă rezoluție „gratuit”, dar nu toate elementele interfeței cu utilizatorul pot face față unei astfel de creșteri Dacă caseta de dialog conține hărți de biți și pictograme sau dacă utilizați o casetă de dialog fără model încorporată într-o casetă de dialog non-dialog, caseta de dialog mărită poate prezenta hărți de biți și pictograme mai mici, trunchiere a textului și aliniere greșită a casetelor de dialog în raport cu cele non-dialog cutii Creați fonturi logice Domeniul de aplicare al fonturilor standard este de obicei limitat la simpla afișare a elementelor interfeței cu utilizatorul Pentru orice alt scop, va trebui să vă creați propriile fonturi logice GDI oferă trei funcții pentru crearea fonturilor logice typedef struct tagLOGFONT { LONG dacă înălțime: LONG IfWidth; LONG IfEscapement; LUNG IfOrientare; LONG fGreutate: LONG Infltalic: LONG Dacă subliniază: LONG fStrikeOut; LONG IfCharSet: LONG IfOutPrecision: LONG fCl pPrecizie Capitolul LONG IfQuality: LONG IfPitchAndFamily; LONG fFaceName[LF FACESIZE]: } LOGFONT *PLOGFONT: typedef struct tagENUMLOGFONTEX { LOGFONT elfLogFont: TCHAR elfFu Nume[LF FULLFACESIZE]: TCHAR elfStyle[LF FACESIZE]: TCHAR elfScriptELFJACESIZE]; }ENUMLOGFONTEX *LPENUMLOGFONTEX; typedef struct tagENUMLOGFONTEXDV { ENUMLOGFONTEX elfEnumLogfontEx; DESIGNVECTOR elfDesignVector: } ENUMLOGFONTEXDV, *PENUMLOGFONTEXDV; HFONT CreateFont(int nHeight, int nWidth, int nEscapement, int nOrientation, int fnWeight, DWORD fdwltalic, DWORD fdwllnderline, DWORD fdwStrikeOut, DWORD fdwCharSet, DWORD fdwOutputPrecision, DWORD fdwClipPrecision, DWORD fdwQuality, DWORD fdwPitchAndFamily LPCTSTR IpszFace); HFONT CreateFontIndirect(CONST LOGFONT * Iplf): HFONT CreateFontIndirectEx(const ENUMLOGFONTEXDV * penumlfex): Parametrii acestor trei funcții descriu cerințele utilizatorului pentru fontul logic generat Funcția CreateFont folosește parametri pentru a descrie un font logic, o înregistrare pentru funcțiile GDI Funcția CreateFontIndirect primește un pointer către o structură LOGFONT care conține toți cei parametri Noua funcție CreateFontIndirectEx, introdusă numai în Windows , ia un pointer către o structură ENUMLOGFONTEXDV Câmpul DESIGNVECTOR este adăugat la structura ENUMLOGFONTEXDV, care conține un nume unic de font, stil și nume de modificări Astfel, cerințele de bază pentru un font logic sunt descrise de structura LOGFONT transmisă în apelul către CreateFontIndirect; funcția CreateFont pur și simplu obține versiunea extinsă a structurii LOGFONT, în timp ce funcția CreateFontIndirectEx folosește doar versiunea extinsă a acestei structuri LOGFONT și alte structuri de fonturi joacă un rol foarte important în înțelegerea fonturilor GDI, așa că trebuie să ne uităm la câmpurile lor principale Despre IfHeight Înălțimea dorită a fontului în unități logice Dacă valoarea este , se utilizează o înălțime standard a fontului de aproximativ puncte Valorile pozitive specifică înălțimea necesară a celulei (adică suma spațierii superscript și indice) Valorile negative determină înălțimea caracterelor din font (spațiere superlinie + spațiere sublinie - spațiere internă) Despre IfWidth Lățimea fontului dorită în unități logice Dacă valoarea este , căutarea se efectuează prin compararea raportului de aspect al dispozitivului grafic cu raportul de aspect al fontului fizic Ecranele și imprimantele au de obicei aceeași rezoluție verticală și orizontală - de exemplu, x dpi sau x dpi În acest caz, zero Fonturi logice valoarea parametrului favorizează fonturile cu un raport de aspect de : Despre IfEscapement Unghiul (în zecimi de grad în sens invers acelor de ceasornic) dintre linia de bază a textului și axa x a dispozitivului De exemplu, fEscapement = înseamnă că tot textul este afișat de-a lungul unei linii de bază paralele cu axa y Aproximativ fOrientare Unghiul (în zecimi de grad în sens invers acelor de ceasornic) dintre linia de bază a fiecărui caracter și axa x a dispozitivului Rețineți că orientarea determină unghiul de rotație pentru caracterele individuale, în timp ce slant (IfEscapement) determină unghiul de rotație pentru întregul șir Dacă dispozitivul rulează în modul grafic avansat (GM ADVANCED), care este disponibil numai pe Windows NT/ , înclinarea și orientarea sunt setate independent În modul grafic compatibil (GM COMPATIBLE) acceptat pe Windows / , câmpul IfEscapement definește fOrientation și valorile acestor câmpuri trebuie să se potrivească Aproximativ fGreutate Greutatea (greutatea) fontului, variind de la la O valoare a FMJDONTCARE ( ) permite GDI să selecteze un font cu greutate arbitrară, FM N RMAL ( ) corespunde greutății medii și FW HEAVY ( ) determină de obicei cel mai îndrăzneț font Aproximativ fi tal ic Dacă acest câmp este setat la TRUE, sunt preferate fonturile italice Aproximativ linie de finanțare Dacă acest câmp este setat la TRUE, textul este subliniat Aproximativ fStrikeOut Dacă valoarea acestui câmp este TRUE, textul este afișat cu barat (o linie este trasată în mijlocul liniei) Aproximativ fCharSet set de caractere font; specifică, de asemenea, codificarea în care șirurile sunt transmise funcțiilor de ieșire a textului GDI Seturile de caractere și codificările sunt descrise în Ce este un font? Capitolul Câmpul al fCharSet are o valoare specială DEFAULT CHARSET Pe Windows / , fontul este determinat de valorile altor câmpuri, în timp ce pe Windows NT/ , se va folosi setul de caractere implicit pentru contextul local al sistemului actual De exemplu, dacă localitatea sistemului este engleză, se utilizează valoarea ANSI CHARSET Când lucrați cu limbi exotice, câmpul fCharSet joacă un rol foarte important în alegerea fontului potrivit, deoarece glifele din setul dorit pot fi acceptate doar de un număr mic de fonturi fizice Aproximativ fOutPrecision Parametri de dorit pentru selectarea fonturilor fizice Valoarea OUT DEFAULT PRECIS specifică modul standard de selectare a fonturilor O valoare OUT DEVICE PRECIS favorizează fonturile dispozitivului, în timp ce o valoare OUT RASTER PRECIS favorizează fonturile bitmap Valoarea OUT OUTLINE PRECIS (numai pentru Windows NT/ ) dă preferință fonturilor de contur, inclusiv fonturilor ThieType Când este setată la OUT TT PRECIS, se acordă preferință fonturilor ThieType, iar când este setată la OUT TT ONLY PRECIS, selecția se face numai între fonturile ThieType Aproximativ fCl i pPrecision Metoda de tăiere a fonturilor Există mai multe steaguri definite pentru acest câmp, dar se pare că numai steagul este relevant pentru tăiere Capitolul CLIP DEFAULT PRECIS (procedura standard de tăiere) Dacă câmpul IfClipPre-cision este CLIP-EMBEDDED, sunt permise fonturile încorporate numai pentru citire Când este specificat indicatorul CLIP LH ANGLES, direcția de rotație a glifelor fontului dispozitivului depinde dacă sistemul de coordonate logic este stângaci sau dreptaci; în caz contrar, fonturile dispozitivului sunt întotdeauna rotite în sens invers acelor de ceasornic Despre IfQuality Calitatea ieșirii glifului Valoarea DEFAULT QUALIYY spune GDI că aspectul simbolurilor nu este important Valoarea DRAFT QUALITY indică faptul că dimensiunea fontului este mai importantă decât calitatea glifului, ceea ce permite GDI să scaleze fonturile bitmap la dimensiunea dorită cu posibilă distorsiune Valoarea PROOF QUALITY indică faptul că calitatea glifului este mai importantă decât dimensiunea fontului, astfel încât scalarea fontului bitmap este dezactivată Pentru fonturile TrueType, constantele DRAFT QUALITY și PROOF QUALITY sunt irelevante, deoarece contururile glifului se scalează liber la dimensiunea dorită Valoarea ANTIALIASED QUALITY determină GDI să efectueze antialiasing text dacă acesta este acceptat de font și fontul în sine nu este nici prea mare, nici prea mic Valoarea NONANTIALIASED QUALITY dezactivează anti-aliasing Despre IfPitchAndFamily Pasul fontului și familia sunt definite în același câmp Cei biți inferiori pot fi DEFAULT PITCH (pasul implicit), FIXED PITCH (font monospațiat) sau VARIABLE PITCH (font proporțional) Biții - definesc familia de fonturi ca constantele FF DECORATIVE, FF DONTCARE, FF MODERN, FF ROMAN, FF SCRIPT și FF SWISS Familiile de fonturi sunt descrise în Ce este un font? capitolul Despre IfFaceName Numele familiei de fonturi Numele familiilor de fonturi instalate în prezent sunt enumerate de funcția EnumFontFamilies Despre elfFulIName Un nume unic pentru font, inclusiv numele companiei, numele fontului, stilurile etc Despre elfStyle Greutatea fontului - de exemplu, bold italic Despre elfScript Numele modificării limbii fontului — de exemplu, chirilic Despre elfDesignVector Font Axes Multiple Mașter OrepType Funcțiile CreateFont, CreateFontIndirect și CreateFontIndirectEx creează un obiect font logic și returnează handle-ul apelantului Apelând funcția GetObject pe un handle de obiect GDI, puteți obține o structură LOGFONT sau ENUMLOGFONTEX care descrie fontul logic Când obiectele font logic nu mai sunt necesare, acestea, ca și alte obiecte GDI, ar trebui șterse cu funcția DeleteObject Când creați un font logic, mai întâi trebuie să calculați înălțimea fontului în coordonate logice Dacă cunoașteți dimensiunea fontului în puncte, ar trebui să o convertiți în coordonate logice folosind contextul dispozitivului de referință Următoarea este o funcție care convertește o dimensiune a fontului în puncte într-o dimensiune dată în coordonate logice // Convertiți punctele în coordonate logice int PointSizetoLogical(HDC hDC int puncte, int divizor) Fonturi logice POINT P[ ] = // Două puncte (POINT) în coordonatele dispozitivului, // distanța dintre care este egală cu înălțimea fontului { { } { , ::GetDeviceCaps(hDC LOGPIXELSY) * puncte / / dlvisor } DPtoLP(hDC P, ); // Convertiți coordonatele dispozitivului // la coordonatele logice return abs(P[l] y - P[O] y): } Funcția PointSizeToLogical primește mânerul de context al dispozitivului de referință, dimensiunea în puncte și un divizor opțional care îmbunătățește precizia calculului În primul rând, punctele sunt convertite în pixeli pe baza rezoluției verticale a dispozitivului, după care valoarea este convertită la o înălțime specificată în sistemul de coordonate logic De exemplu, înălțimea unui font de puncte este calculată apelând PointSizetoLogi cal(hDC, ), în timp ce pentru un font de , puncte, este folosit PointSizetoLogical(hDC, , ) Pe dispozitivele de înaltă rezoluție (să zicem, o imprimantă de dpi), fiecare pixel are , puncte, astfel încât partea fracțională a dimensiunii poate afecta formatarea textului Completarea celor câmpuri ale unei structuri LOGFONT sau transmiterea a parametri la funcția CreateFont este o procedură plictisitoare care este adesea predispusă la erori Listarea arată o clasă simplă KLogFont care încapsulează structura unui font logic LOGFONT Lista Clasa KLogFont: încapsularea structurii KLogFont a clasei LOGFONT public: LOGFONT m Dacă; KLogFont(int helght, const TCHAR * typeface=NULL) m lf IfHeight m lf IfWidth m lf IfEscapement m lf IfOrientation mJf lfWeight m lf Ifltalic m lf tunderii ne m lf lfStrikeOut m lf IfCharSet m lf IfOutPrecision m lf Qualf IfClip IfClip m lf IfPitchAndFamily = DEFAULT PITCH | FF DONTCARE: =inaltime: = ; = : = ; = FW NORMAL: = FALS: = FALS: = FALS; = ANSI-CHARSET: = OUT TT PRECIS: = CLIP DEFAULT PRECIS: = DEFAULT-CALITATE; if ( font ) tcsncpy(m lf IfFaceName, font, LF FACESIZE- ); altfel Continuare Capitolul Lista Continuare m lf fFaceNameCOJ = : } HFONT Creare font(void) { return ::CreateFontIndirect(& } int GetObject(HFONT hFont) { return ::GetObject(hFont, sizeof(m lf) & } }• Clasa KLogFont reduce numărul de parametri de la la Restului parametrilor li se atribuie valori implicite rezonabile care pot fi modificate prin câmpurile variabilei publice m lf Următorul fragment creează un font italic logic de de puncte pentru fontul Times New Roman: KLogFont lf(- PoIntSIzetoLoglcal (hDC ), „Times New Roman”: If m lf Iftalic = TRUE: HFONT hFont = If CreateFontO: Înlocuirea fontului Un font logic nou creat de funcția CreateFont, CreateFontIndirect sau CreateFontIndirectEx nu este asociat cu niciun font fizic deoarece nu este încă asociat cu un context de dispozitiv Atunci când alegeți un font logic într-un context de dispozitiv, GDI se confruntă cu sarcina de a alege un font fizic care se potrivește cu descrierea dată Acest proces se numește potrivire a fonturilor În timpul înlocuirii, GDI verifică cerințele de font logic cu toate datele despre font disponibile pentru dispozitivul grafic În plus față de fonturile care sunt instalate permanent pe sistem, fonturile încorporate și fonturile dispozitivului pot participa și la înlocuire Capitolul v-a arătat cum să încorporați un font într-un document, să îl instalați când documentul se deschide și să obțineți o listă a fonturilor instalate Fonturile de dispozitiv sunt acceptate de driverul dispozitivului grafic și sunt implementate de dispozitivul grafic în hardware De exemplu, o imprimantă PostScript acceptă în mod obișnuit câteva zeci de fonturi PostScript și transmite informații despre acestea către GDI, astfel încât aceste fonturi să fie folosite la ieșirea textului De obicei, aplicația utilizator formatează textul pe baza valorilor solicitate din contextul dispozitivului Când primește direct comenzi de ieșire, driverul de imprimantă poate genera comenzi care utilizează fonturi de dispozitiv în loc să încarce fonturi ThieType În fonturile clasice Windows bitmap și vector, structura antetului fontului este foarte asemănătoare cu structura TEXTMETRIC utilizată în GDI Structura TEXTMETRIC conține aproape aceleași date ca și LOGFONT - înălțime, lățime medie, greutate, familie și tip, cursiv, subliniat, barat etc GDI selectează fără efort fontul potrivit prin potrivire Fonturi logice Lăsând conținutul LOGFONT cu un titlu de font Cu alte cuvinte, crearea de fonturi logice bazate pe structura LOGFONT este axată pe lucrul cu fonturi bitmap și vector Fonturile TrueType și OpenType conțin informații mult mai detaliate despre caracteristicile unui font fizic Valorile fonturilor TrueType/OpenType sunt stocate într-un tabel de valori OS/ și Windows similar cu structura GDI OUTLINETEXTMETRIC Cel mai important factor în selectarea unui font fizic este setul de caractere Deși majoritatea fonturilor acceptă setul ANSI, caracterele din alte limbi sunt uneori acceptate doar de o mică parte din fonturile instalate pe sistem De exemplu, fonturile suportă foarte rar caractere decorative Când o aplicație solicită un anumit set de caractere, GDI face toate eforturile pentru a găsi un font care să accepte acel anumit set de caractere; în caz contrar, caracterele pot fi afișate ca glife complet greșite Fonturile bitmap și vectoriale acceptă un singur set de caractere; un font TrueType poate suporta zeci de seturi Fiecare font TrueType/OpenType stochează un câmp de semnalizare pe de biți care definește codificările acceptate de font De asemenea, se acordă o mare atenție acurateței rezultatelor Această măsură restricționează candidații la anumite tipuri de fonturi De exemplu, OUT OUTLINE-PRECIS favorizează fonturile de contur Fonturile monospațiate arată foarte diferit de fonturile proporționale, așa că tipul fontului este, de asemenea, un factor important atunci când se înlocuiesc O atenție primordială este acordată numelui setului cu cască Când găsește un font fizic cu o potrivire exactă a numelui tipului de literă care se potrivește cu alți factori importanți (set de caractere, înălțime, cursiv și greutate), subsistemul de fonturi GDI nu mai caută Registrul de sistem stochează o listă de sinonime pentru numele tipurilor specificate de utilizator De exemplu, această listă ar putea spune sistemului de înlocuire a fonturilor că „Heiv” este un sinonim pentru „MS Sans Șerif”, „MS Shell Dig” este un sinonim pentru „Microsoft Sans Șerif”, iar „Times” este un sinonim pentru „Times” Nou Roman” Alți factori importanți de luat în considerare în procesul de înlocuire a fonturilor bitmap sunt familia de fonturi, înălțimea, lățimea și raportul de aspect Pentru fonturile de contur, greutatea fontului, sublinierea, barajul, înălțimea, lățimea și raportul de aspect nu mai sunt atât de semnificative Sistem de înlocuire a fonturilor PANOSE După cum puteți vedea, procesul de selectare a fonturilor în funcție de datele LOGFONT pare destul de logic Cu toate acestea, ia în considerare numai datele care sunt transmise în apelurile către CreateFont/CreateFontIndirect și stocate în anteturile de fonturi bitmap și vector Dacă documentul este trimis la un computer cu un set diferit de fonturi, situația este mult mai complicată Să presupunem că un document stochează informații despre un font cu caracterul Antique Olive Compact într-o structură LOGFONT Cum ar trebui să procedeze GDI pentru a ridica fontul fizic corect? Capitolul Deși structura OUTLINETEXTMETRIC a fonturilor TriType/OpenType conține o copie a structurii simple TEXTMETRIC, mijlocul principal de clasificare a fonturilor este structura PANOSE Sistemul de înlocuire a fonturilor PANOSE este conceput pentru a clasifica și potrivi fonturile în funcție de aspectul lor Fonturile ThyeType folosesc în prezent tehnologia PANOSE , care descrie un font cu caracteristici pentru un singur octet: typedef struct tagPANOSE { BYTE bFamilyType: BYTE bSerlfStyle; BYTE bWelght; BYTE bProportlon; BYTE bContrast; BYTE bStrokeVariatlon: BYTE barArmStyle; BYTE bLetterForm; BYTE bLinie mediană; BYTE bxHelght: } PANOSE, * LPPANOSE: Spre deosebire de structura LOGFONT, care are doar două câmpuri ( fWeight și IfPitchAndFamily) referitoare la aspectul fontului, structura PANOSE pune bazele unei înlocuiri mai precise a fonturilor În special, stiluri diferite serif sunt definite în PANOSE - pătrat, triunghiular, rotunjit etc Structura PANOSE oferă o modalitate compactă și eficientă de clasificare și înlocuire a fonturilor într-un sistem Pentru fiecare font FontType/OpenType, se completează o structură PANOSE și gradul de similitudine dintre cele două fonturi este evaluat prin „distanța” dintre punctele corespunzătoare din spațiul de caracteristică a fontului cu dimensiuni PANOSE merge chiar mai departe, folosind de valori pentru a descrie fonturile Pentru mai multe informații despre sistemul de înlocuire a fonturilor PANOSE, consultați www fonts com/hp panose/index htm Deși tehnologia PANOSE oferă un rezultat mult mai bun decât înlocuirea fonturilor bazată pe structurile LOGFONT și TEXTMETRIC, nu există funcții în GDI care să o susțină direct Funcțiile CreateFont, CreateFontIndirect și CreateFontIndirectEx nu folosesc structura PANOSE atunci când definesc un font logic De fapt, funcționarea algoritmului de înlocuire a fonturilor PANOSE se bazează pe interfața COM IPANOSEMapper implementată într-una dintre bibliotecile de sistem puțin cunoscute panmap dll În special, această interfață este utilizată de aplicația Control Panel Fonts atunci când utilizatorul solicită o grupare de fonturi similare Pe fig Figura prezintă sistemul de înlocuire a fonturilor PANOSE în acțiune Figura arată cum arată fereastra aplicației atunci când alegeți comanda Vizualizare ► Lista fonturi după asemănare (Vizualizare ► Grupare fonturi similare) Dacă Tahoma este ales ca referință, atunci Verdana este etichetat ca „foarte asemănător”, Arziai este etichetat ca „foarte asemănător”, iar Courier este etichetat ca „nu este similar” Pentru unele fonturi, există o intrare în listă că informațiile nu sunt disponibile (adică nu există date PANOSE) Fonturi logice Mă adresez { Fonts ^"#A> ^A^ ' •• \ > ' ' f Fișier £"& Favorite Xsyub kMP Usl fonte de jagif fo: Nume ShiarftMo Tahoma „ :: ,£>] Tahoma Foarte asemănătoare €?] Verdana Foarte asemănătoare Arial Destul de asemănător І Arial Black Destul de asemănător Arial Narrow Destul de asemănător Fft Rnnkman Rid Rhdp Faitln asemănătoare L fontfo) {plus fidden) Orez Mecanismul PANOSE în aplicația panoului de control Lista arată o clasă simplă pentru lucrul cu interfața IPANOSE-Marreg Lista Clasa KFontMapper: folosind interfața IPANOSEMapper clasa KFontMapper { IPANOSEMapper * m pMapper; const PANOSE * m pFontList; int m nFontNo; public: KFontMapper(void) { m pMapper = NULL; m pFontList = NULL; m nFontNo = ; Colni ti ali ze(NULL); CoCreateInstance(CLSID PANOSEMapper, NULL CLSCTX INPROC SERVER IIDJPANOSEMapper, (void **) & m pMapper); } void SetFontList(const PANOSE * pFontList, int nFontNo) { m pFontList = pFontList; mjiFontNo = nFontNo: } int PickFonts(const PANOSE * pTarget, unsigned short * pOrder unsigned short * pScore, int nResult) { Continuare Capitolul Lista Continuare m pMapper->vPANRelaxThreshold(); Int rslt = m pMapper->unPANP ckFonts( Ordin // pScore, // (BYTE *) pTarget, // nResult, // (BYTE *) ni-pFontLIst, // m nFontNo, // Comanda (de la cel mai bun la cel mai rău) Rezultatul căutării metrica PANOSE pentru comparație Numărul de fonturi returnate metrica PANOSE a primului font sizeof(PANOSE), pTarget->bFamiIyType): m pMapper->bPANRestoreThreshold(): returnează rslt; } ~KFontMapper() { If ( m pMapper ) m pMapper->Release(); CoUnlnltlalizeO: Numărul de fonturi comparat Pe lângă constructor și destructor, clasa KFontMapper conține două funcții Funcția SetFontList populează o serie de structuri PANOSE pentru fonturile disponibile Funcția PickFonts preia metrica PANOSE și încearcă să găsească potriviri bune pentru aceasta Rezultatele sunt returnate în două matrice - fonturi și distanțe dintre structura originală PANOSE și opțiunile potrivite Pentru a utiliza clasa KFontMapper, trebuie rezolvate două probleme Primul este să determinați valoarea PANOSE pentru fontul pe care îl înlocuiți Al doilea este de a construi o bază de date cu valori PANOSE pentru toate fonturile disponibile în sistem Într-o soluție posibilă, metrica PANOSE este stocată împreună cu structura LOGFONT în document Când un font logic este creat și selectat într-un context de dispozitiv, GDI potrivește fontul logic cu fontul fizic instalat pe sistem Funcția GDI GetOutlineTextMetric returnează o structură OUTLINETEXTMETRIC pentru un font fizic Câmpul otmPanoseNumber al acestei structuri stochează metrica PANOSE Valoarea PANOSE este salvată în formatele RTF (Rich Text Format) și EMF (Enhanced Metafile) Formatul RTF este utilizat de câmpurile de text îmbogățit, fișierele de ajutor native ale sistemului Windows, aplicații precum WordPad și chiar Microsoft Word Există un articol în baza de cunoștințe MSDN care menționează eroarea Word Deși formatul RTF utilizat în Word păstrează valorile PANOSE cu fonturi, Word ignoră acele valori atunci când înlocuiește fonturile lipsă O căutare a cuvântului „PANOSE” în fișierul antet GDI wingdi h arată că acesta este utilizat în structura EXTLOGFONT Structura EXTLOGFONT este o extensie a LOGFONT cu nume de tip și stil complet calificate, ID de dezvoltator, metrica PANOSE etc Astfel, structura Fonturi logice conține informații despre fonturile logice și fizice Destul de ciudat, nicio funcție GDI documentată nu primește sau returnează o structură EXTLOGFONT Singura utilizare documentată a EXTLOGFONT este într-o structură EMREXTCREATEFONTINDIRECTW utilizată pentru a scrie o comandă pentru a crea un font logic în format EMF Sarcina de a construi o bază de date cu numere PANOSE pentru toate fonturile disponibile poate părea simplă În capitolul , am învățat cum să folosim funcția EnumerateFontFamiliesEx pentru a obține o listă a tuturor familiilor de fonturi din sistem Pentru fiecare familie, EnumerateFontFamiliesEx apelează funcția transmisă de aplicație și îi transmite o structură NEWTEXTMETRICEX care stochează un câmp pentru metrica PANOSE, printre alte date interesante Dar problema este că aceste funcții nu listează fonturi fizice, ci familii de fonturi, fiecare familie fiind de obicei listată de mai multe ori pentru fiecare codificare acceptată De exemplu, există patru fonturi diferite în familia Arial: Arial, Arial Bold, Arial Bold Italic și Arial Italic, dar funcția EnumerateFontFamiliesEx le consideră a fi o singură familie Arial, care este listată de ori pentru fiecare modificare acceptată (latina, ebraică, arabă, greacă) , turcă, baltică, central-europeană, chirilică și vietnameză) Desigur, fontul Arial este vizibil diferit de Arial Bold Italic, dar funcția EnumerateFontFamiliesEx scoate o singură familie de fonturi și ascunde toate celelalte Dacă îl utilizați pentru a popula baza de date PANOSE, baza de date va fi incompletă De fapt, o astfel de bază de date este deja stocată în registrul Windows prin cheie HKEY LOCAL MACHINE\SOFTWARE\M crosoft\Shared Tools\Panose Lista fonturilor fizice instalate este stocată în registru după cheie SOFTWAREWMicrosoftWWindows NTWCurrentVersionWFonts Ca urmare a iterării listei de fonturi fizice, puteți obține numele fonturilor și le puteți filtra, lăsând doar fonturile ThieType/OpenType Pe baza numelui fontului, creați un font logic, îl selectați în contextul dispozitivului și îl mapați la un font fizic Dacă fontul fizic găsit este un font ThieType/OpeType, valoarea sa PANOSE poate fi preluată cu funcția GetOutlineTextMetrics Funcția din Lista - , având un nume de cască, returnează valoarea PANOSE și numele setului cu cască înlocuit Tehnicile de enumerare a fonturilor sunt discutate în capitolul Lista Obțineți valoarea PANOSE după numele căștilor // 'Arial Bold Italic' -> PANOSE bool GetPANOSECHDC hDC const TCHAR * nume complet, PANOSE * panose TCHAR facenameED { Nume TCHAR[MAX PATHp // Eliminați spațiile de început în timp ce (nume complet[O]==' ') nume complet ++: Continuare^ Capitolul Lista Continuare tcscpy(nume ful cale): // Eliminați spațiile de sfârșit pentru (Int i= tcslen(nume)-l: ( >= ) && (nume[ ]==' '): ) nume[i] = : LOGFONTlf: memset(&lf, sizeof(lf)): lf IfHeight = : lf lfCharSet = DEFAULT CHARSET; lf IfWeight = FW REGULAR: if ( strstrCname, „Italic”) lf Inflatalic=TRUE: if ( strstrCname „Aldin”) lf IfWeight = FW BOLD; tcscpy(lf IfFaceName name): HFONT hFont = CreateFontIndirect(&lf): if ( hFont==NULL ) returnează false; HGDIOBJ hold = SelectObject(hDC hFont): { KOutlineTextMetric otm(hDC); dacă ( otm GetName(otm m pOtm->otmpFaceName) ) { -tcscpyCfacename otm GetName(otm m pOtm->otmpFaceName) ); * panose = otm m pOtm->otmPanoseNumber; } altfel facename[ ] = ; } SelectObject(hDC Hold); DeleteObject(hFont): returnează numele față[ ] != : } Pe fig Figura - prezintă fereastra PANOSE Font Matching a programului demo Font Locul principal în acesta este ocupat de o listă cu toate fonturile disponibile și atributele acestora Dacă faceți clic dreapta pe unul dintre rândurile din listă, valoarea PANOSE a acelui font este comparată cu valorile PANOSE ale tuturor celorlalte fonturi Fereastra din partea dreaptă a figurii arată rezultatele comparației pentru fontul Courier New Vă rugăm să rețineți că fontul MingLiU nu are o metrică PANOSE, ceea ce duce la o anumită distorsiune a rezultatelor Acest font ar trebui exclus din matricea de numere PANOSE din ri- Obținerea de informații despre un font logic Imaginea arată că Courier New este aproape de Andale Mono, Lucida Console, Georgia și Palatino Linotype Courier New Text and Display Thin Curier Nou în text vechi și Afișare subțire Curier Nou în vechiul I talie T ext și Display Thin Courier New I talie T ext și Display Thin Lucida Console Text and Display Normal Sans Lucida S ans U mcode T ext and Display N ormal S ans Times New Roman T ext și Display Cove Times New Roman B T ext și Display Cove Times New Roman B T ext și Display Cove Times New Roman It T ext și Display Cove Wingdmgs Pictorial Oricare Simbol Pictural Obtuz Sq Verdana T ext și Display Normal Sans ; A Lumină Monospațiată Niciuna Mediu Mono:&x ✓ Medium Mopol L f Thin Mono; QQ SO Coufter New CourwHewBdd Medium Old St ZhidSh Mediu Modei WW Bold Modei Demi Modei Z Andale Mono Book Modei Soigj New Bdd Italie Orice orice W Cupida Contate No Fit Old St Mediu Even' Palatin Lindy pe [ OK eu Orez Ilustrație a sistemului de înlocuire a fonturilor PANOSE Calitatea înlocuirii fonturilor lipsă poate fi îmbunătățită în mai multe moduri De exemplu, în timpul construcției documentului, împreună cu structura LOGFONT, puteți stoca metrica PANOSE împreună cu alte date de font fizic Structura EXTLOGFONT utilizată în EMF poate fi luată ca exemplu Când un document este deschis pe alt computer, aplicația verifică dacă fontul fizic furnizat de GDI este similar cu fontul fizic utilizat pe computerul original Gradul de similitudine este evaluat prin compararea numelor complete ale fonturilor sau a numerelor lor PANOSE Dacă aplicația decide că fontul original nu este disponibil în sistem și înlocuirea propusă este inacceptabilă, ea realizează înlocuirea ea însăși Pentru a face acest lucru, își poate construi propria bază de date de numere PANOSE pentru toate fonturile disponibile, poate găsi înlocuirea optimă folosind clasa KFontMapper sau alt instrument și apoi poate regenera fonturile logice pentru cei mai buni candidați găsiți pe mașina locală Obținerea de informații despre un font logic După ce obiectul font logic creat este selectat în contextul dispozitivului, GDI selectează un font fizic pentru acesta dintre cele instalate pe sistem Când se întâmplă acest lucru, booleanul este asociat cu fontul implementat Fontul implementat nu trebuie confundat cu cel fizic; este doar o instanță specifică a unui font fizic cu o anumită dimensiune, raport de aspect, unghi de rotație, imitație de caracteristici speciale etc De exemplu, fontul fizic Times New Roman poate exista în mai multe încarnări la un moment dat; unul se va potrivi cu lo Capitolul un font grafic de puncte pentru un ecran de dpi, celălalt este un font logic de de puncte pentru o imprimantă de dpi, rotit la de grade Implementarea unui font fizic este o operațiune complexă și consumatoare de timp, care necesită multă memorie După cum am văzut în Capitolul , fonturile TrueType sunt foarte complexe și dificil de analizat și căutat în forma lor originală Pentru a găsi un glif pentru un caracter dintr-o anumită codificare, caracterul trebuie convertit în Unicode și apoi găsiți indexul glifului folosind un tabel special În timpul construcției unui glif, contururile sale sunt scalate la dimensiunile specificate, ținând cont de instrucțiunile stocate în font și apoi convertite într-un formular bitmap O implementare primitivă care pornește ieșirea fiecărui caracter prin maparea codului caracterului la indexul glifului ar fi prohibitivă pentru performanța sistemului În practică, motorul grafic menține structuri complexe de date care descriu corespondența dintre obiectele fontului logic și fișierele fontului fizic În Windows NT/ , pentru fiecare font fizic utilizat, este creată o structură de date (PFF) în spațiul de adrese kernel care conține o listă legată de implementări de fonturi (FONTOBJ) Fiecare structură FONTOBJ are un cache de glife construite pentru reutilizare Fiecare obiect font logic are un pointer către un obiect GDI nedocumentat, un obiect PFE, care conține referințe la obiectele PFF corespunzătoare Această organizare complexă a datelor permite cache-ul și reutilizarea eficientă a fonturilor implementate la nivel de sistem, permițând în același timp GDI să creeze, să utilizeze și să șteargă liber fonturi logice Structurile interne de date ale motorului grafic legate de lucrul cu fonturile sunt descrise în detaliu în Capitolul După ce un font logic este selectat în contextul dispozitivului, puteți obține mai multe informații despre fontul fizic selectat și despre valorile implementării curente a fontului fizic Pentru aceasta sunt utilizate următoarele funcții: Int GetTextFace(HDC hDC Int nCount, LPSTR IpFaceName); DWORD GetFontLanguageInfo(HDC hDC); Int GetTextCharSet(HDC hDC): Int GetTextCharSetInfo(HDC hDC LPFONTSIGNATURE IpSig, DWORD dwFlags): BOOL GetTextMetrics(HDC hDC, LPTEXTMETRIC Iptm); UINT GetOutHneTextMetrics(HDC hDC, UINT cData, LPOUTLINETEXTMETRIC IpOtm); Funcția GetTextFace returnează numele fontului fizic corespunzător fontului logic în contextul dispozitivului (poate fi diferit de numele fontului utilizat pentru a crea fontul logic) Funcția GetFontLanguagelInfo returnează informații despre fontul curent selectat în contextul dispozitivului, inclusiv suport pentru glife pe doi octeți, prezența semnelor diacritice, prezența unui tabel de kerning și așa mai departe Informațiile obținute folosind această funcție sunt adesea folosite în -formatare trivială a textului (de exemplu, atunci când lucrați direct cu glife folosind funcțiile GetCharacterPl sau ExtTextOut) Obținerea de informații despre un font logic Funcția GetFontLanguagelInfo returnează o combinație de mai multe steaguri, dintre care cele mai comune sunt FLI GLYPHS ( x ) și GCP USERKERNING ( x ) Indicatorul FLI GLYPHS înseamnă că fontul conține simboluri suplimentare care nu pot fi accesate prin codificarea curentă Steagul GCPUSERKERNING înseamnă că fontul are un tabel de kerning Dacă computerul dvs are suport pentru limba arabă sau ebraică, pentru unele fonturi TrueType, funcția GetFontLanguagelnfo returnează indicatoarele GCPREORDER, GCP GLYPHSHARE, GCP LIGATE, GCP DIACRITIC și GCP KASHIDA De exemplu, fonturile Arial, Lucida Sans Unicode, Tahoma și Andalus acceptă GCPREORDER, în timp ce „Times New Roman” nu Funcția GetTextCharset returnează identificatorul setului de caractere pentru fontul curent selectat în contextul dispozitivului Această valoare poate fi utilizată pentru a verifica dacă fontul fizic acceptă setul de caractere cerut de fontul logic De exemplu, dacă setul HANGUL CHARSET a fost solicitat la crearea unui font logic, dar sistemul dumneavoastră nu are niciun font coreean, GDI poate alege un set de caractere implicit; în acest caz, funcția GetTextCharset va returna ANSI CHARSET Funcția GetTextCharsetInfo returnează o structură FONTSIGNATURE cu informații despre subintervalele Unicode și codificări acceptate de fontul FontType/OpenType Primele patru dwords FONTSIGNATURE formează un USB de de biți (câmp de biți de subset Unicode), iar celelalte două dwords formează un CPB de de biți (câmp de biți de pagină de cod) De exemplu, bitul al USB indică dacă glifele chirilice sunt acceptate, iar bitul al СРВ indică suportul pentru codarea (Thai) Fontul Tahoma din RTB este setat la biți, deoarece acest font conține glife din codificări diferite Funcțiile GetTextMetrics și GetOutlineTextMetrics returnează valori importante despre implementarea actuală a fontului fizic Funcția GetTextMetrics returnează o structură TEXTMETRIC Pentru fonturile TrueType/OpenType, funcția GetOutlineTextMetrics returnează o structură OUTLINETEXTMETRIC, o versiune extinsă a TEXTMETRIC care conține informații suplimentare Valori de font raster și vectorial Structura TEXTMETRIC a fost concepută inițial pentru titluri în Windows bitmap și fonturi vectoriale, dar este potrivită și pentru fonturile TrueType/OpenType Pentru a obține structura TEXTMETRIC completă pentru fontul curent selectat în contextul dispozitivului, apelați funcția GetTextMetrics cu mânerul de context al dispozitivului și un pointer către TEXTMETRIC Structura TEXTMETRIC este definită după cum urmează: typedef struct tagTEXTMETRIC { LUNG tmÎnălțime; LONG tmAscent; LONG tmDescent: LONG tmlInternalLeading; LONG tmExternalLeading; LONG tmAveCharWldth; Capitolul LONG tmMaxCharWldth: LUNG tmGreutate; LUNG tmDepășire: LONG tmDigitizedAspectX LONG tmDigltlzedAspectY BYTE tmFirstChar; BYTE tmLastChar: BYTE tmDefaultChar; BYTE tmBreakChar; BYTE tmltalic: BYTE tmSubliniat; BYTE tmStruckOut: BYTE tmPitchAndFamlly: BYTE tmCharSet; TEXTMETRIC: Câmpul tmAscent definește spațierea superscriptului (înălțimea caracterului deasupra liniei de bază) Câmpul tmDescent definește distanța dintre linii (înălțimea părții caracterului de sub linia de bază), iar câmpul tmHeight definește înălțimea totală a caracterului (tmAscent+tmDescent) - vezi fig Câmpul tmlnternalLeading definește cantitatea de interliniere internă, spațiul în care sunt plasate de obicei accentele și semnele diacritice, iar câmpul tmExternalLeading definește interfața exterioară, spațierea suplimentară recomandată între linii Diferența dintre tmHeight și tmlnternalLeading corespunde mărimii fontului, valorii standard pentru dimensiunea caracterelor De exemplu, pentru un font de de puncte într-un context de ecran de dpi și în modul MM TEXT, câmpul IfHeight al structurii LOGFONT ar fi - ( x , ) Dacă creăm un font logic din această structură LOGFONT și îl selectăm în contextul dispozitivului de ecran, câmpul tmHeight al structurii TEXTMETRIC returnat de funcția GetTextMetrics va fi , iar câmpul tmlnternalLeading va fi Diferența dintre ele este , valoarea absolută a câmpului IfHeight al structurii LOGFONT Pentru fonturile bitmap, când scalarea este dezactivată (steagul PROOF QUALITY din câmpul IfQuality al structurii LOGFONT), uneori GDI nu reușește să potrivească cu precizie fontul cu dimensiunea dată De exemplu, pentru un font cu puncte în fontul Terminal, câmpul IfHeight din structura IfHeight este - , dar câmpul tmHeight poate fi cu o spațiere internă de Dacă un font bitmap nu poate fi găsit la dimensiunea dată , se folosește de obicei un font mai mic Suma tmHeight și tmExternalLeading este distanța dintre linii recomandată Înălțimea a n linii de text este calculată prin formulă tmÎnălțime x n + tmExternalLeading x (n - ) deoarece nu este nevoie de spațiu suplimentar înainte de prima și după ultima linie Să presupunem că un font de de puncte într-un context de ecran de dpi și în modul MM TEXT are un câmp tmHeight de și un câmp tmExternal-Leading de Înălțimea totală a liniei este de de unități sau , puncte Trebuie reținut că diferite fonturi de aceeași dimensiune pot avea valori diferite ale câmpurilor tmHeight și tmExternalLeading sau suma lor Câmpul tmAveCharWidth specifică lățimea medie a caracterelor a fontului Documentația Microsoft spune că lățimea medie este de obicei egală cu lățimea liniei Obținerea de informații despre un font logic Noe litera „x” În fonturile TpіeType/OpType, lățimea medie a caracterelor este calculată mai precis ca suma ponderată a lățimilor literelor minuscule az latine și spațiului În fonturile monospace, toate caracterele au aceeași lățime, iar câmpul tmAveCharWidth poate fi folosit pentru a calcula lungimea unui șir de caractere Lățimea medie a caracterelor este utilizată și la selectarea fonturilor Câmpul tmMaxCharWidth stochează lățimea maximă de caractere a fontului Câmpul tmWeight determină greutatea fontului și este același cu câmpul IfWeight al structurii LOGFONT Rețineți că toate resursele de fonturi bitmap și vector, precum și fonturile fizice TrueType, au o greutate fixă O font TrueType conține de obicei patru ponderi fizice: obișnuit, cursiv, aldine și cursiv aldine Saturația primelor două ponderi este de obicei (FW NORMAL), iar ultimele două sunt (FW BOLD) GDI încearcă să găsească cea mai bună potrivire pentru o anumită greutate dintre fonturile disponibile Dacă nu poate fi găsită o potrivire exactă, GDI simulează saturația dorită folosind un algoritm simplu Câmpul tmOverhang specifică cantitatea de spațiu suplimentar utilizată de GDI atunci când sintetizează fonturi Dacă saturația necesară depășește cea disponibilă, GDI îngroșează caracterele; dacă se solicită caracterul cursiv și nu este disponibil niciun font fizic cursiv, GDI înclină ușor glifele În ambele cazuri, dimensiunea rândului crește ușor Câmpul tmOverhang permite aplicației să calculeze cu precizie dimensiunile orizontale ale șirului de caractere, astfel încât să nu depășească spațiul alocat În practică, acest câmp este diferit de zero pentru fonturile bitmap și vector, în timp ce pentru fonturile TrueType/Open-Type este întotdeauna zero De exemplu, pentru fontul italic de de puncte Wingdings, care are doar o greutate fizică obișnuită, câmpul tmOverhang returnează Câmpul tmFi rstChar specifică primul caracter pentru care fontul are un glif; câmpul tmLastChar specifică ultimul caracter Ambele câmpuri sunt declarate cu tipul BCHAR (WCHAR în Unicode, BYTE în alte codificări) Fonturile bitmap și vectoriale conțin glife pentru toate caracterele din intervalul tmFi rstChar până la tmLastChar În fonturile TPieType/OpenType, versiunile pe un singur octet ale câmpurilor tmFi rstChar și tmLastChar nu sunt suficiente pentru a reprezenta adevărata gamă de caractere pentru care fontul are glife, iar versiunile Unicode ale câmpurilor nu înseamnă că fontul conține glife pentru toate caracterele dintre tmFi rstChar și tmLastChar Câmpul tmDefaultChar definește caracterul de înlocuire pentru caracterele care nu au un glif în font (de obicei o casetă dreptunghiulară) Fonturile TrueType folosesc în mod implicit primul glif de la indexul Câmpul tmBreakChar specifică caracterul prin care sunt determinate rupturile de cuvinte atunci când textul este aliniat Următoarele trei câmpuri sunt denumite în mod similar câmpuri LOGFONT Câmpul tmltalic este diferit de zero dacă este necesar cursiv; câmpul tmUnderline este diferit de zero dacă caracterele sunt subliniate, iar câmpul tmStruckOut este diferit de zero dacă este necesar ca caracterele să fie subliniate Rețineți că aceste câmpuri reflectă doar cerințele specificate în obiectul font logic, nu și caracteristicile fontului fizic Stilurile care nu sunt într-un font fizic sunt sintetizate folosind GDI Capitolul Câmpul tmPitchAndFamily specifică tipul, tehnologia și familia fizică de fonturi Jumătatea înaltă a câmpului este aceeași cu jumătatea înaltă a câmpului IfPitchAndFamily din structura LOGFONT Jumătatea inferioară este formată din patru steaguri independente și este diferită de jumătatea inferioară a lui IfPitchAndFamily O TMPF FIXED PITCH ( x ) - Setat pentru fonturi proporționale Totul este răsturnat - de ce nu numiți acest câmp TMPF PROP PITCH? О TMPF VECTOR ( x ) - setat pentru fonturile de contur (cu alte cuvinte, pentru toate fonturile cu excepția bitmap) o TMPF TRUETYPE ( x ) - Setat pentru fonturile TPieType/OpenType o TMPF DEVICE ( x ) - Setat pentru fonturile dispozitivului Ultimul câmp tmCharSet definește setul de caractere al fontului logic Valoarea sa este aceeași cu câmpul fCharSet al structurii LOGFONT (dacă nu este DEFAULT CHARSET) și valoarea returnată a funcției GetTextCharSet Un font TrueType/OpenType acceptă de obicei mai multe seturi de caractere, informații despre care pot fi obținute folosind funcția GetTextCharlInfo Valorile fonturilor TrueType/OpenType Fonturile TrueType/OpenType au un număr mult mai mare de valori pentru care a fost dezvoltată structura OUTLINETEXTMETRIC Prefixul „out-line” poate fi confuz deoarece această structură nu se aplică fonturilor vectoriale, ci doar TrueType/OpenType și fonturilor de dispozitiv pentru care driverul de font poate furniza o structură OUTLINETEXTMETRIC Mai jos este definiția structurii OUTLINETEXTMETRIC typedef struct -OUTLINETEXTMETRIC { UINT otmSize; TEXTMETRIC otmTextMetrics; BYTE otmFiller: PANOSE otmPanoseNumber: UINT otmfsSelection; UINT otmfsType; Int otmsCharSlopeRise; Int otmsCharSlopeRun; int otmltalicAngle; UINT otmEMSquare; Int otmAscent; int otmDescent: UINT otmLineGap; UINT otmsCapEmHeight; UINT otmsXHeight: RECT otmrcFontBox; int otmMacAscent; int otmMacDescent: UINT otmMacLineGap: UINT otmusMinimumPPEM: POINT otmptSubscriptSize; POINT otmptSubscript ptOffset; POINT otmptSuperscri ptSize: Obținerea de informații despre un font logic POINT otmptSuperscriptOffset: UINT otmsStrikeoutSize; Int otmsStrikeoutPosi ti on; Int otmsUndercoreSize: int otmsUndercorePosi ti on; PSTR otmpFamilyName; PSTR otmpFaceName: PSTR otmpStyleName: PSTR otmpFulIName; } OUTLINETEXTMETRIC: Odată ce a fost selectat un ghid de font logic în contextul dispozitivului (presupunând că are un font fizic TrueType/OpenType), puteți apela funcția GetOutlineTextMetrics și puteți prelua structura OUTLINETEXTMETRIC completată din GDI În timp ce structura OUTLINETEXTMETRIC nu pare atât de complicată (cu excepția numărului mare de câmpuri), această simplitate este înșelătoare Descrierea OUTLINETEXTMETRIC din documentația Microsoft lasă mult de dorit În primul rând, această structură este variabilă în dimensiune, deoarece ultimele patru câmpuri ale sale conțin decalaje de linie, care sunt de obicei atașate blocului de date după ultimul câmp Aici se află al doilea truc: ultimele patru câmpuri nu stochează pointeri, așa cum este indicat în declarație, ci decalaje relativ la începutul blocului de date Ultimul câmp se numește otmSize, iar numele sugerează că înainte de a apela GetOutlineTextMetrics, dimensiunea structurii trebuie introdusă în acest câmp Nu trebuie neapărat să faceți acest lucru, deoarece dimensiunea blocului de date este transmisă în al doilea parametru al GetOutlineTextMetrics Deoarece structura OUTLINETEXTMETRIC are o dimensiune variabilă, funcția GetOutlineTextMetrics trebuie apelată de două ori La primul apel, obțineți dimensiunea reală a structurii, alocați un bloc de dimensiunea corectă și îl transmiteți la al doilea apel pentru a obține datele CD-ul inclus conține clasa KOutlineTextMetric pentru a obține structura OUTLINETEXTMETRIC Mai jos este declarația acestei clase clasa KOutlLineTextMetric {public: OUTLINETEXTMETRIC * m pOtm; KOutlineTextMetric(HDC hDC); -KOutl neTextMetric(); }: Constructorul clasei KOutlineTextMetric primește o structură OUTLINETEXTMETRIC într-un bloc de memorie alocată în heap Destructorul eliberează memorie atunci când instanța clasei iese din domeniul de aplicare Dacă v-ați uitat la codul pentru această clasă, este posibil să fi observat o verificare ciudată a decalajului pentru câmpul otmFiller Cea mai insidioasă proprietate a structurii OUTLINETEXTMETRIC este că câmpurile sale trebuie să se alinieze la o limită de cuvinte duble Această limitare nu este documentată și nu este impusă de fișierele antet Windows Autorul a petrecut câteva zile încercând să-și dea seama de ce structura OUTLINETEXTMETRIC returnată de funcția GetOutlineTextMetrics nu se potrivește cu declarația Răspunsul a fost găsit numai la vizualizarea unui dump de date binare Capitolul Al doilea câmp OUTLINETEXTMETRIC conține o structură TEXTMETRIC de lungime n + octeți Proiectantul acestei structuri a adăugat o umplere de un octet (otmFiller), astfel încât următoarea structură PANOSE să fie aliniată la cuvinte Rețineți că acest cadru a fost dezvoltat pentru Windows Winl API, când Windows a introdus pentru prima dată suport pentru fonturile ThieType Probabil, la compilarea textelor sursă GDI, a fost stabilită alinierea câmpurilor structurilor de-a lungul limitei a octeți Ca urmare, câmpul otmFiller a ajuns să fie aliniat cu două cuvinte și au fost adăugați trei octeți în fața acestuia Structura PANOSE are o lungime de octeți; următorul câmp otmfsSelection trebuie să înceapă pe o limită de cuvinte duble, astfel încât încă doi octeți sunt adăugați înaintea acestuia De obicei, atunci când are loc o aliniere specială a câmpurilor de structură, o directivă #pragma pack este inclusă în fișierele de antet Windows pentru a furniza tipul de aliniere dorit și pentru a înlocui tipul de aliniere specificat în programul utilizatorului Acest lucru asigură că aplicația va funcționa cu aceleași structuri Win API, indiferent de configurația proiectului Nu există o astfel de directivă în fișierul wingdi h pentru structura OUTLINETEXTMETRIC La momentul scrierii acestui articol, alinierea DWORD în fișierul antet a avut loc numai dacă a fost definită macro-ul MAC Dacă proiectul dvs necesită ca câmpurile de structură să fie aliniate pe o limită de sau octeți și doriți să utilizați structura OUTLINETEXTMETRIC, asigurați-vă că treceți la alinierea cuvintelor duble: #pragma pack(push, ) # nclude #pragma pack(pop) Primul câmp, otmSize, determină dimensiunea întregii structuri, inclusiv șirurile încorporate Este urmată de structura TEXTMETRIC (vezi mai sus), care este exact aceeași cu cea returnată de apelul GetTextMetric Al treilea câmp otmFiller a fost menit să alinieze structura PANOSE care o urmează pe o limită de cuvânt Se pare că sursele GDI au fost compilate cu câmpuri de structură aliniate pe granițe de sau octeți, rezultând trei octeți ascunși după otmTextMetrics și înainte de otmFiller Câmpul otmPanoseNumber stochează valoarea PANOSE pentru fontul fizic Este urmat de doi octeți ascunși, asigurându-se că următorul câmp este aliniat pe o limită de cuvânt dublu Câmpul otmfsSelection descrie stilul fontului folosind o combinație de steaguri Bit ( x ) este setat pentru font italic, bit ( x ) este pentru subliniat, bit ( x ) este pentru negativ, bit ( x ) este pentru font contur, bit ( x ) este pentru barat, bit ( x ) pentru bold și bit ( x ) pentru normal Fontul ThieType are un atribut numit similar care poate fi folosit pentru a identifica designul original al fontului fizic De exemplu, setarea biților și înseamnă că fontul fizic este bold (adică bold nu este sintetizat de GDI) Se pare că GDI folosește acest câmp puțin diferit; otmfsSelection reprezintă caracteristicile unui font logic, nu unui font fizic, deci nu puteți spune din valoarea câmpului otmfsSelection dacă un font fizic este aldine O sursă de încredere de informații despre caracteristicile fizice ale fontului este structura PANOSE; de exemplu, conținutul câmpului bLetterForm poate determina dacă fontul este italic Obținerea de informații despre un font logic Câmpul otmfsType definește drepturile de licență pentru încorporarea fontului în documente (consultați Instalarea și încorporarea fonturilor în Capitolul ) Următoarele trei câmpuri sunt legate de ieșirea textului cu accent Pentru fonturile verticale, marcajul este o linie verticală subțire care indică poziția de introducere a următorului caracter În editorii de text profesioniști, semnul de semnătură cu caractere cursive este afișat într-un unghi Câmpul otmltal icAngl e specifică unghiul fontului în zecimi de grad în sens invers acelor de ceasornic față de axa y Pentru fonturile verticale, câmpul otmltalicAngl e este , în timp ce pentru fonturile italice conține de obicei un număr negativ Înclinarea căruciorului este determinată de raportul dintre câmpurile otmsCharSlopeRise și otmsCharSlopeRun Pentru fonturile verticale, câmpul otmsCharSlopeRise este , iar câmpul otmsCharSlopeRun este , deci marcajul arată ca o linie verticală De exemplu, fontul italic „Times New Roman” are un câmp otmltalicAngle de - , un câmp otmsCharSlopeRise de și un câmp otmsCharSlopeRise de Tangenta de , ° este , , care este foarte aproape de / ( , ) ) Toate cele trei caracteristici se referă la fontul fizic; sinteza fonturilor italice prin intermediul GDI nu le afectează în niciun fel De exemplu, încercați să lucrați cu fontul italic Tahoma, care nu are un font italic fizic WordPad afișează o liniuță verticală, în timp ce editorul Word mai priceput afișează unul oblic Câmpul otmEMSquare conține dimensiunea em-square a fontului fizic Esh-square este grila de referință pe care sunt construite glifele Toate punctele dintr-o descriere a glifului sunt reprezentate prin coordonate întregi em-square, astfel încât mărirea dimensiunii em-pătratului îmbunătățește de obicei calitatea pictogramelor Acest câmp este utilizat de obicei de aplicații pentru a defini parametrii sistemului de coordonate logice Pentru mai multe informații despre definirea glifelor TrueType, consultați Capitolul Câmpul otmAscent specifică spațierea tipografică în superscript al fontului, câmpul otmDescent specifică spațierea sublinie tipografică, iar câmpul otmLineGap specifică spațierea sublinie tipografică GDI folosește propria interpretare a spațierii în indicele și indicele, precum și spațierea internă și externă, care în unele cazuri coincide cu interpretarea tipografică, iar în altele diferă de aceasta O altă diferență este că câmpul otmDescent este de obicei negativ, deoarece indicele este sub linia de bază, iar Windows folosește întotdeauna modulul (valoarea absolută) a acestei metrici Grupul de câmpuri otmMacAscent, otmMacDescent și otmMacLineGap conține valori verticale pentru fontul Macintosh Documentația Microsoft spune că câmpurile otmCapEmHeight și otmXHeight nu sunt acceptate Probabil, câmpul OtmCapEmHeight ar trebui să conțină înălțimea literei mari fără un descendent, iar câmpul otmXHeight ar trebui să conțină înălțimea literei x minuscule Câmpul otmrcFontBox definește caseta de delimitare a tuturor glifelor din font, în raport cu punctul de bază al caracterului Câmpul otmrcFontBox left are de obicei o valoare negativă corespunzătoare valorii A minime, iar câmpul otmrcFontBox bottom are o valoare negativă corespunzătoare celui mai mare indice Câmpul otmusMinimumPPEM definește dimensiunea minimă permisă în pixeli la care em-square poate fi redus conform recomandării dezvoltatorului Capitolul font Valoarea acestui câmp indică cât de bine sunt potrivite instrucțiunile de legare pentru a construi caractere mici Valoarea obișnuită este de sau pixeli Câmpurile otmptSubscriptSize și otmptSubscriptOffset definesc dimensiunea și poziția subscriptelor fontului de la punctul de bază al caracterului Câmpurile otmptSuperscriptSize și otmptSuperscriptOffset conțin date similare pentru superscripte Câmpurile otmsStrikeoutSize și otmsStrikeoutPosition determină grosimea traseului orizontal atunci când caracterele sunt șterse și poziția acesteia față de linia de bază Câmpurile otmsUndercoreSize și otmsUndercorePosition definesc grosimea și poziția în raport cu linia de bază a traseului utilizat pentru subliniere Pe fig Figura prezintă unele dintre noile valori conținute în structura OUTLINETEXTMETRIC - și anume, căsuța de delimitare, superscript/indicele, sublinierea, barajul și valorile oblice de caractere Cele cinci linii punctate indică nivelurile decalajului exterior, ascensoarelor, decalajului interior, liniei de bază și descendentului Conturul mare se potrivește cu caseta de delimitare a fontului și pare prea mare Două dungi gri simulează sublinierea și barajul Cele două dreptunghiuri din dreapta reprezintă dimensiunea punctului de bază și a indicelui/indicelui Linia înclinată reprezintă unghiul caracterului utilizat în ieșirea căruciorului Orez Valorile fonturilor în structura OUTLINETEXTMETRIC Ultimele patru câmpuri ale structurii OUTLINETEXTMETRIC conțin decalajele numelor de familie, font și stil, precum și numele complet al fontului fizic, de la începutul structurii Este mai ușor de explicat ceea ce s-a spus cu un exemplu concret Există un font fizic pentru Times New Roman aldine cursive, astfel că ultimele patru câmpuri OUTLINETEXTMETRIC conțin linia Times New Roman, Times New Roman Bold Italic, Bold Italic și Mono-type Times New Roman Bold Italic Versiunea - (Microsoft) decalaje Obținerea de informații despre un font logic Structura LOGFONT și valorile fonturilor Programul Font care însoțește acest capitol vă va ajuta să înțelegeți mai bine relația dintre fonturile logice definite de structura LOGFONT și fontul fizic Acest program modifică dialogul standard de selecție a fontului și afișează toate informațiile despre fontul din el API-ul Win conține funcția ChooseFont pentru a afișa o casetă de dialog standard în care utilizatorul selectează un font logic Această caracteristică permite unei aplicații să suprascrie mecanismul implicit de gestionare a mesajelor într-o casetă de dialog Prin trecerea funcției ChooseFont la un apel indirect, obținem informații suplimentare despre structura curentă LOGFONT și valorile implementării actuale a fontului fizic În programul Font de pe CD-ul inclus, dialogul fontului se extinde la dreapta pentru a afișa un arbore ierarhic cu toate atributele fontului Caseta de dialog de selectare a fontului modificat este prezentată în fig În partea stângă (dialog de selectare a fontului original) este selectat fontul aldin Times New Roman cu dimensiunea de de puncte Arborele ierarhic copil (Tgee-View) afișează rezultatele apelurilor către GetTextFace, GetFontLanguagelInfo, GetTextCharset, GetTextCharsetInfo, GetTextMetrics și GetOutlineTextMetrics în structura LOGFONT Pe fig În Figura , structura OUTLINETEXTMETRIC este extinsă, arătând structuri imbricate TEXTMETRIC și PANOSE și câteva câmpuri inițiale Dacă selectați un rând diferit în partea stângă a ferestrei și faceți clic pe butonul Săgeată, conținutul arborelui ierarhic este sincronizat cu rândul selectat OiSHZHTECHTMEZHS JZ B Trebuchet MS Despre Verdana Despre Webdings Wide Latin Despre Wingdings :• otmSize: •ti-otmTextMetrics: TEXTMETRIC î+ otmPanoseNumber: PANOSE otmfsSelection: x otmfsType: otmsCharSlopeRise: ••• otmsCharSIopeRun: ■■■■ otmltahcAngle:- ■ ■■ otmEMSquare: ; otmAscent: =• otmDescent: - LOGFONT GetTextFace: Times New Roman GetFontLanguagelInfo: x GetTextCharset: x FONTSIGNATURE TEXTMETRIC Noul Ronw '■ abcB = size cx: ABC abc: GetCharABCWidths(hDC, IpStringEO], lpString[O], & abc): // Primul caracter pABC->abcB -= abc abcA: pABC->abcA = abc abcA; GetCharABCWi dths(hDC, pStri ngEcbStri ng- ] pStringLcbString- J și abc): // Ultimul caracter pABC->abcB -= abc abcC: pABC->abcC = abc abcC: returnează TRUE: } Pentru linia prezentată în fig , GetTextABCExtent returnează structura ABC {- , ,- }; aceasta înseamnă că lungimea reală a șirului este de de unități, cu șirul decalat cu - de unități de la punctul de plecare Când funcția TextOut aliniază un șir în funcție de atributele text-align, valorile A și C sunt ignorate Dacă valoarea A a primului caracter este negativă, o parte din glif poate dispărea Dacă valoarea A este pozitivă, textul este aliniat incorect la dreapta (mai ales când aliniați textul în fonturi diferite sau același font cu dimensiuni diferite) Următorul fragment arată cum să aliniați cu precizie textul la nivel de pixel utilizând funcția GetTextABCExtent Ieșire text simplă BOOL PreciseTextOut(HDC hDC, int x, int y, LPCTSTR IpString, int cbString) { inaltime lunga: ABC abc; if ( GetTextABCExtent(hDC, IpString, cbString și înălțime și abc) ) comutați ( GetTextAlign(hDC) & (TA LEFT | TA RIGHT | TA CENTER) ) { caz TA LEFT : x -= abc abcA; pauză; caz TA DREPTA : x += abc abcC: break; caz TA-CENTER; x -= (abc abcA-abc abcC)/ ; pauză: } returnează TextOut(hDC, x, y, IpString, cbString): } Funcția PreciseTextOut calculează valorile ABC pentru întregul șir și modifică coordonata x a apelului TextOut în funcție de indicatorul curent de aliniere a textului orizontal Orez Figura - ilustrează diferențele dintre implementarea standard a alinierii GDI și ajustările făcute de funcția PreciseTextOut Prima coloană arată rezultatele unui apel normal TextOut la stânga, centrul și dreapta justifică un șir Părțile de glife care se extind dincolo de cele două linii de delimitare sunt de obicei tăiate - ca, de exemplu, în celulele tabelelor Word sau Excel În a doua coloană, aceleași linii sunt afișate cu o ușoară corecție calculată de funcția PreciseTextOut; alinierea asigură acuratețea la nivel de pixel Orez Alinierea textului: TextOut și PreciseTextOut În operațiunile interne ale motorului grafic, este utilizat sistemul de coordonate al dispozitivului, din care tot textul scalat Capitolul metrici Dacă maparea de la sistemul de coordonate al dispozitivului la sistemul de coordonate logic nu este redusă la scalarea cu un factor întreg, obținerea de valori folosind funcția GetTextABCWidths poate duce la o eroare și la acumularea ulterioară de erori în calcule Funcția GetTextABCWidthsFloat ajută la eliminarea erorii care apare la transformarea coordonatelor Dacă aplicația dvs trimite text atât pe ecran, cât și pe imprimantă, trebuie acordată o atenție deosebită pentru a vă asigura că datele de pe ecran se potrivesc cu datele tipărite De exemplu, pentru a obține valori exacte ale textului, puteți utiliza un font logic de referință (consultați secțiunea „Obținerea de informații despre un font logic”) Ieșire de text non-trivială Funcția TextOut este foarte simplă și oferă o interfață convenabilă pentru facilitățile de ieșire a textului GDI Când utilizați această funcție, aplicația setează mai multe atribute de context de dispozitiv și transmite un șir Funcția este limitată la cea mai simplă ieșire și maschează complet din aplicație toate operațiunile complexe efectuate de GDI la ieșirea textului Costul comodității și simplității este că aplicația nu poate controla modul în care caracterele sunt convertite în glife, ordonarea glifelor, ligaturi și kerning, pozițiile individuale ale glifelor și așa mai departe Pentru a rezolva problemele non-triviale de ieșire a textului, GDI oferă funcții speciale utilizate în editorii de text modern și în alte pachete grafice Conversia caracterelor în glife Un font TrueType este centrat pe un set de descrieri de glife care sunt scalate la orice rezoluție și convertite în glife Caracterele diferitelor codificări sunt de obicei convertite mai întâi în Unicode și apoi în indexuri de glife, conform tabelului „vechi” stocat în fontul TrueType Unele funcții de procesare a textului care nu sunt suportate direct de GDI sunt ușor de implementat la nivel de glif Windows GDI a introdus o nouă funcție GetGlyphIndices care permite unei aplicații să obțină o serie de indici de glife pentru caracterele dintr-un șir În versiunile anterioare de Windows, această conversie a fost realizată folosind funcția GetCharacterPlacement, descrisă mai jos Windows GDI acceptă și funcții pentru obținerea de informații despre valorile glifului: DWORD GetGlyphInd ces(HDC hDC LPCTSTR Ipstr int c LPWORD pgi DWORD fl); BOOL GetCharW dth(HDC hDC, UINT giFirst UINT cgi LPWORD pgi LPINT pBuffer): BOOL GetCharABCWidthsKHDC hDC UINT giFirst uint cgi LPWORD pgi LPABC Ipabc): BOOL GetTextExtentPointKHDC hDC LPWORD pgiIn int cpi, LPSIZE IpSize): Ieșire de text non-trivială Indicii de glife sunt stocați ca numere întregi de biți (WORD) Caracterele Unicode sunt, de asemenea, stocate ca numere întregi pe biți, astfel încât indicii glifului reprezintă întreaga gamă Unicode Pentru a obține informații despre spațierea Unicode suportată de un font, utilizați funcția GetFontUnicodeRanges Funcția GetGlyphIndices mapează un șir de text la o matrice de indici glifi Parametrul pdi indică o matrice WORD suficient de mare pentru a conține toți indecșii Ultimul parametru, fl, îi spune lui GDI cum să facă față caracterelor lipsă Dacă este egal cu CGI MASK NONEXISTING GLYPHS, caracterele lipsă sunt înlocuite cu un marcator OxFFFF În mod implicit, glifele lipsă din fonturile TrueType sunt reprezentate de primul glif al fontului Generatoarele de metrici de text GetCharWidthl, GetCharABCWidthsI și Get-TextExtentPointI sunt foarte asemănătoare cu omologii lor fără sufixul I, cu o excepție – sunt intervale transmise sau matrice de index glif atunci când sunt apelate Funcțiile API la nivel de glif vă permit să efectuați operațiuni specifice care nu sunt suportate direct de GDI Dacă o aplicație dorește să implementeze ligaturi sau substituție de glif in loc, poate prelua tabelul de fonturi TrueType corespunzător cu funcția GetFontData și poate căuta în tabel Structura internă a fonturilor TrueType este tratată în detaliu în Capitolul kerning Atunci când pur și simplu scoateți text cu funcția TextOut, caracterele sunt poziționate într-o linie numai după spațiile dintre caractere stocate în fontul TrueType, și anume valorile glifului ABC Spațierea suplimentară între caractere este pur și simplu aplicată fiecărui caracter care este scos, indiferent de specificul acestora Fonturile TrueType conțin de obicei date de kerning pentru a oferi ajustări de spațiere la locul lor Datele de kerning sunt codificate într-un tabel de kerning, al cărui element (o pereche de kerning) definește parametrii de ajustare a spațierii pentru două caractere adiacente specifice Pentru a obține perechi de kerning, aplicația folosește funcția GetKerning-Pairs: typedef struct tagKERNINGPAIR { Cuvântul întâi: CUVÂNT w În al doilea rând: int IKernAmount: } KERNINGPAIR: DWORD GetKerningPairs(HDC hDC, DWORD nNumPairs LPKERNINGPAIR Ipkrnpair): Fiecare pereche conține două coduri de caractere, wFirst și wSecond, și o valoare de kerning Ceea ce înseamnă de fapt este că, dacă un caracter wFirst este urmat de un caracter wSecond în același font, distanța dintre cele două caractere este ajustată de iKernAmount De obicei, perechile de kerning sunt setate la o spațiere negativă, astfel încât caracterele să se apropie unul de celălalt, Capitolul cu toate acestea, distanța poate fi și pozitivă Cantitatea de kerning returnată de funcția GetKerningPairs este într-un sistem de coordonate logic Un font TrueType poate conține sute de perechi de kerning Pentru a obține informații despre toate perechile, trebuie mai întâi să apelați funcția GetKerningPairs pentru a obține numărul total de perechi După alocarea unui bloc de memorie de dimensiune suficientă, funcția este apelată din nou pentru a obține datele de kerning Mai jos este declarația unei clase simple pentru lucrul cu perechi de kerning (implementarea completă este pe CD-ul inclus) clasa KKerningPair { public: KERNINGPAIR * m pKerningPairs; int mjiPairs; KKerningPair(HDC hDC): -KKerningPair(void): int GetKerningfTCHAR mai întâi tchar secundă) }: Clasa KKerningPair conține două variabile Variabila m pKerningPairs indică o matrice alocată dinamic de structuri KERNINGPAIR, iar variabila m nPairs deține numărul de perechi de kerning pentru fontul curent Constructorul clasei solicită numărul de perechi de kerning, iar destructorul eliberează resursele alocate Metoda suplimentară GetKerning returnează valoarea de kerning pe baza a două coduri de caractere Exemple de kerning sunt prezentate în fig Textul din rândul de sus este afișat fără kerning Imaginea din stânga sus arată patru perechi de simboluri prea depărtate, în timp ce dreapta sus arată trei perechi de simboluri prea apropiate Kerning face ca caracterele din imaginea din stânga să se apropie unul de celălalt (ajustare negativă) și caracterele din imaginea din dreapta să se îndepărteze (ajustare pozitivă) Orez Exemple de perechi de kerning Aranjamentul caracterelor Lucrul direct cu indicii de glif și datele de kerning într-o aplicație este dificil GDI are o funcție utilă de acțiune GetCharacterPl, Ieșire de text non-trivială returnează informații despre locația caracterelor dintr-un șir Aplicația poate analiza datele primite, le poate modifica sau le poate folosi în alte scopuri Definițiile relevante arată astfel: typedef struct tabGCP RESULTS { DWORD IstructSize: LPTSTR pOutString: UINT* pOrder; INT * IPDx; INT * IpCaretPos; LPTSTR IpClass; LPWSTR * IpGlyphs: UINT nGlyphs; UINT mMaxFit: } GCP RESULTS; DWORD GetCharacterPlacement(HDC hDC, LPCTSTR IpString, int nCount, int nMaxExtent, LPGCP RESULTS IpResults, DWORD dwFlags): Funcția GetCharacterPlacement primește un indicator de context al dispozitivului, un pointer către un șir de text și lungimea acestuia, o lățime opțională a zonei de text și un set de steaguri Ca rezultat, populează o structură GCP RESULT cu informații despre aranjarea caracterelor într-un șir: ordinea caracterelor, spațierea caracterelor, poziția marcajului, clasificarea caracterelor, indecșii glifelor și numărul de caractere care se potrivesc într-o anumită regiune Structura GCP RESULT în sine nu conține toate informațiile, deoarece aceste date sunt reprezentate de matrice de dimensiune variabilă; Structura stochează pointeri către matrice Aplicația trebuie să pregătească în mod corespunzător REZULTATUL GCP înainte de a apela acement GetCharacterPl Dacă o aplicație solicită anumite informații, setează indicatorul necesar în ultimul parametru, iar câmpul GCP RESULTS corespunzător trebuie să conțină un pointer valid; în caz contrar, valoarea câmpului poate fi NULL Funcția GetCharacterPlacement este foarte puternică, concepută pentru a sprijini diverse aspecte ale procesării textului - justificare, kerning, diacritice, ordonarea glifelor, ligaturi și așa mai departe Capacitățile specifice depind de font și de configurația curentă a sistemului În special, nu toate fonturile ThieType conțin tabele de kerning și ligaturi de suport Capacitățile unui anumit font pot fi verificate folosind funcția GetFontLanguagelInfo O descriere completă a caracteristicilor GetCharacterPlacement ar ocupa prea mult spațiu Consultați MSDN pentru detalii Aici, vor fi luate în considerare câteva cazuri simple - utilizarea indicatoarelor GCP USERKING, GCP MAXENTENT și GCPJUSTIFY În structura REZULTATE GCP, câmpul pOutputString conține un pointer către șirul de ieșire care urmează să fie scos pentru șirul de intrare dat De regulă, șirul de ieșire este același cu șirul de intrare, dar șirurile pot diferi - de exemplu, când setați steagurile GCP REORDER (schimba ordinea caracterelor) și GCP MAXEXTENT (depășește limita de lungime a șirului de intrare) Câmpul pOrder conține un pointer către o matrice plină cu date pentru maparea șirului de intrare la șirul de ieșire În ebraică și arabă, textul este afișat în partea dreaptă Capitolul spre stânga, ceea ce poate modifica ordinea caracterelor din șirul de intrare Câmpul IpDx conține un pointer către o matrice plină cu informații despre lățimea fiecărui caracter din șir (adică diferența dintre distanța dintre pozițiile caracterului curent și următorul din șir) Această distanță este determinată de lățimea completă a caracterului cu toate modificările - spațiere suplimentară între caractere, spații crescute între cuvinte și kerning Ordinea elementelor din tabloul IpDx corespunde ordinii caracterelor din șirul de ieșire Câmpul pCaretPos indică o matrice umplută cu poziții marcaj pentru toate caracterele în ordinea în care apar în șirul de intrare Datele pot fi folosite de un editor de text pentru a muta semnul de semnătură pe măsură ce funcționează Informațiile despre unghiul caracterelor sunt stocate în structura OUTLINETEXTMETRIC Câmpul IpClass conține o serie de caracteristici de clasificare pentru toate caracterele șirului De exemplu, steagul GCPCLASS ARABIC denotă un caracter arab Câmpul pGlyphs conține un indicator către o matrice umplută cu indici de glif ai tuturor caracterelor din șir Folosind această matrice, puteți obține indecși de glif fără a utiliza funcția GetGlyphIndices, care este acceptată numai pe Windows Dacă același șir de text este utilizat în apeluri de mai multe funcții, ar trebui să obțineți indecșii o dată și să îi utilizați din nou - acest lucru va economisi timp pe conversii multiple Câmpul nGlyphs conține inițial numărul maxim de elemente din diferite matrice ale structurii GCP RESULTS Când GetCharacterPlacement iese, acesta este scris în numărul de elemente utilizate efectiv în matrice Câmpul nMaxFit conține numărul de caractere care se încadrează în zona specificată de parametrul GetCharacterPlacement Rețineți că câmpul nMaxFit stochează numărul de caractere, spre deosebire de câmpul nGlyph care conține numărul de glife CD-ul conține o clasă simplă de acțiune KP pentru a lucra cu funcția GetCharacterPlacement Funcția ExtTextOut Obținerea indicilor de glife, a datelor de kerning și a informațiilor despre plasarea caracterelor nu este altceva decât o pregătire pentru ieșirea textului Pentru a aplica informațiile primite la afișarea textului, ar trebui să utilizați funcția ExtTextOut BOOL ExtTextOut(NO hDC, int x Int ym UINT fuOptions CONST RECT * Iprc LPCTSTR IpString UINT cbCount CONST INT * IpDx): Funcția ExtTextOut este o versiune extinsă a TextOut Apelul la TextOut poate fi înlocuit cu apelul echivalent la ExtTextOut: ExtTextOut(hDC, x y NULL, IpString cbCount, NULL); Rămâne doar să ne ocupăm de trei parametri noi Parametrul fuOptions conține un set de steaguri care controlează interpretarea altor opțiuni Parametrul opțional rcs indică un dreptunghi care poate defini limitele unei zone opace, poate fi folosit pentru tăiere sau o combinație a acestor funcții Parametrul opțional IpDx conține un pointer către o serie de distanțe În tabel listează valorile valide pentru parametrul fuOptions Ieșire de text non-trivială Tabelul Indicatori ale funcției ExtTextOut Descrierea valorii ETO OPAQUE ( x ) Înainte ca textul să fie afișat, dreptunghiul specificat de parametrul Iprc este umplut cu o culoare de fundal ETO CLIPPED ( x ) Textul este decupat la dreptunghiul specificat de parametrul Iprc ETO GLYPH INDEX ( x ) Parametrul IpString indică o matrice de indici de glife (în loc de coduri de caractere) Indicii glifilor sunt întotdeauna valori pe biți ETO RTLREADING ( x ) La fel ca indicatorul TA RTLREADING pentru alinierea textului Fonturile arabe și ebraice afișează textul de la dreapta la stânga ETO NUMERICSLOCAL ( x ) Numerele sunt afișate în alfabete naționale ETO NUMERICSLATIN ( x ) Numerele afișate în cifre europene standard ETO IGNORELANGUAGE ( x ) Nu efectuați procesare suplimentară a limbii pe text ETO PDY ( x ) Parametrul pDx indică o matrice de perechi unde primul număr definește distanța orizontală și al doilea distanța verticală Parametrul Iprc al funcției TextOut nu afectează redarea normală de fundal; mai degrabă, facilitează afișarea textului într-o zonă limitată, cum ar fi o celulă de tabel Dacă parametrul Iprc este non-NULL, acesta este interpretat ca un pointer către un dreptunghi în sistemul de coordonate logic Când steag ETO OPAQUE este setat, dreptunghiul este umplut cu culoarea de fundal curentă împreună cu fundalul text implicit Cu indicatorul ETO CLIPPED setat, dreptunghiul specifică un nivel suplimentar de tăiere în sistemul de coordonate logic (nu în coordonatele dispozitivului!) Pentru a scoate un șir de text într-o celulă de tabel, o aplicație poate trece dreptunghiul celulei către ExtTextOut și poate seta ambele steaguri ETO OPAQUE și ETO CLIPPED În acest caz, întregul dreptunghi al celulei, și nu doar zona de text, este umplut cu culoarea actuală de fundal, iar textul cu siguranță nu va încălca limitele celulei Parametrul IpDx permite aplicației să determine cu exactitate poziția fiecărui glif fără a se baza pe ajutorul GDI Cu această arhitectură, aplicația poate procesa în continuare structura de plasare a caracterelor generată de funcția GetCharacterPlacement Amintiți-vă că valorile text returnate de GDI unei aplicații sunt în sistemul de coordonate logic, iar rezultatul textului este în sistemul de coordonate al dispozitivului Când imprimați un document creat pe un ecran de monitor pe o imprimantă de înaltă rezoluție care are valori mult mai precise, aspectul textului nu se va potrivi exact cu aspectul ecranului Pentru a rezolva aceste două probleme de nepotrivire (între coordonatele logice/coordonatele dispozitivului și coordonatele ecranului/imprimantei), o aplicație poate obține date precise privind valorile fontului dintr-un font logic de referință care are aceeași dimensiune cu pătratul em al punctului fizic Capitolul fontul cerului Toate calculele poziționale sunt făcute pe datele exacte em-square și scalate în sistemul de coordonate logic, stocate într-o matrice și transmise la ExtTextOut Funcția ExtTextOut poate fi, de asemenea, utilizată pentru a scoate un șir de text bazat pe indici de glife obținuți folosind funcțiile GetGlyphIndices sau GetCharacterPlacement Următoarea metodă emite un șir de text bazat pe conținutul structurii GCP RESULTS returnat de funcția GetCharacterPlacement BOOL KPlacement::GlyphTextOut(HDC hDC, int x int y) { returnează ExtTextOut(hDC xy ETO GLYPH INDEX, NULL, (LPCTSTR) m glyphs, m gcp nGlyphs, m dx): Următorul fragment ilustrează un exemplu de utilizare a indicilor de glif și a kerningului atunci când lucrați cu funcțiile GetCharacterPlacement și ExtTextOut void Test Kerning(HDC hDC, int x int y, const TCHAR * mess) { TextOut(hDC, x, y, mizerie, Jxslen(mizerie)): KPlacement plasare; TEXTMETRIC tm: GetTextMetrics(hDC, &tm): int linespace » tm tmHeight + tm tmExternalLeading: KKerningPair kerning(hDC): DIMENSIUNE Marime: GetTextExtentPoint (hDC, mess, tcslen(mess) & size): pentru (int test= ; test plasare; const TCHAR * mess = "abc\xC \xC \xC \xCA": SetTextA gn(hDC, TA LEFT); Capitolul placement GetPlâcement(hDC, mess, ): placement GlyphTextOut(hDC, x, yO); SetTextAl gn(hDC, TA LEFT | TA RTLREADING); placement GetPlacement(hDC, mess, GCP REORDER): placement GlyphTextOut(hDC, x, yl); Pe fig arată un rezultat foarte interesant ordine[ ] = , ordine[ ]= , ordine[ ] = , ordine[ ] = , ordine[ ] = , ordine[ ] = , ordine[ ] = , ordine [ ] = , ordine[ ]■ , ordine Г ] = , ordine[ ] = , ordine[ ] = , ordine[ ] = , ordine[ ] = , ordine[ ] = , ordine[ ] = , gi( x )= , dx[ ]= gi( x )= , dx[l]= gi( x )= , dx[ ]= gi( x )= , dx[ ]= gi( xc )= , dx[ ]= gi( xc )= , dx[ ]= gi( xc )= , dx[ ]= gi(Oxca)= , dx[ ] = gi(Oxca)= , dx[ ]= gi( xc )= , dx[l]= gi( xc )= , dx[ ]= gi( xc )= , dx[ ]= gi( x )= , dx[ ]= gi( x )= , dx[ ]= gi( x )= , dx[ ]= gi( x )= , dx[ ]= Orez Reordonarea și înlocuirea glifelor Comparați cele două linii, de sus și de jos: cuvintele sunt schimbate, ordinea caracterelor este inversată, iar personajele înseși se mapează la diferite glife În prima linie, caracterele sunt afișate în ordinea standard - de la stânga la dreapta, de la primul la al optulea În a doua linie, ordinea atât a cuvintelor, cât și a caracterelor arabe s-a schimbat Caracterele arabe se mapează la diferite glife, în funcție de poziția lor relativă în cuvânt Să presupunem că litera „aleph” ( xC ) se mapează la gliful în prima linie și la gliful în a doua linie Uniscrie Windows a introdus componenta Uniscribe, un nou API care oferă un grad ridicat de control asupra procesării complexe a textului „Text complex” se referă la orice text care folosește ieșire bidirecțională, înlocuire de glife pe loc, ligături, reguli speciale de formulare și justificare sau filtrarea combinațiilor de caractere nevalide Textele complexe includ texte ebraice, arabe, thailandeze și sanscrite API-ul Uniscribe este extrem de complex, cu peste de funcții noi și structuri noi Uniscribe folosește fișierul antet usplO h, fișierul bibliotecă usplO lib și biblioteca usplO dll Și când considerați că usplO dll este mai mare decât gdi dll, puteți vedea de ce nu există loc în această carte pentru o discuție despre Uniscribe Începând cu Windows , funcțiile standard de ieșire a textului GDI (cum ar fi TextOut și ExtTextOut) au fost extinse pentru a accepta text complex Ieșire de text non-trivială Cu toate acestea, utilizarea efectivă a acestor caracteristici depinde dacă acestea sunt acceptate la nivel de font și setările curente ale sistemului Când parcurgeți codul funcției text GDI, veți vedea că GDI încarcă biblioteca externă lpk dll, unde LPK înseamnă „Language Pack” Ipk dll exportă zeci de funcții numite LpkDrawTextEx, LpkExtTextOut și LpkTabbedTextOut și importă o serie de funcții din usplO dll Aspectul din dreapta și ordonarea caracterelor, înlocuirea glifelor — în Windows , toate aceste caracteristici se bazează pe utilizarea Uniscribe Procesarea complexă a textului a fost întotdeauna o slăbiciune a API-ului Windows GDI, mai ales în comparație cu QuickDraw GX de la Apple Înainte de apariția Uniscribe, o aplicație care furniza text non-trivial a trebuit să funcționeze la nivelul tabelelor interne de fonturi ThieType Utilizarea Uniscribe simplifică foarte mult procesarea textelor complexe în aplicații Accesarea datelor glifului După cum sa menționat mai sus, glifele din fonturile ThieType sunt reprezentate de curbe Bézier pătratice Când textul este scos, conturul glifului este convertit într-un bitmap cu dimensiunile și unghiul specificate Rasterele rezultate sunt afișate pe suprafața dispozitivului în conformitate cu solicitările aplicațiilor Cu toate acestea, capacitatea de a afișa text în GDI rămâne limitată De exemplu, GDI nu permite unei aplicații să folosească o pensulă sau un bitmap pentru a desena text; sunt permise doar culori uniforme Pentru aplicațiile non-triviale care necesită o procesare specială a glifelor înainte de ieșire, GDI oferă o funcție de nivel scăzut GetGlyphOutline Cu această funcție, aplicația solicită date de glif sub forma unui set de valori, un raster sau o descriere a căii Definițiile relevante sunt date mai jos typedef struct GLYPHMETRICS { UINT gmBlackBoxX: UINT gmBlackBoxY; POINT gmptGlyphOrlgin: scurt gmCellIncX; scurt gmCellIncY; } GLIFMETRIC; typedef struct FIXED { Fragment de CUVÂNT: valoare scurtă; } FIXAT: typedef struct MAT { eMll FIX: FIX eM ; FIX eM : eM FIX: }MAT : DWORD GetGlyphOutline(HDC hDC UINT uChar, UINT uFormat, Capitolul LPGLYPHMETRICS Ipgm, DWORD cbBuffer, LPVOID IpvBuffer, CONST MAT *lpmat ): Funcția GetGlyphOutline poate returna unul dintre cele trei tipuri de date pentru un caracter într-un singur apel: valori de glif, raster de glif sau contur de glif Primul parametru specifică contextul dispozitivului cu fontul ThieType/OpenType selectat Parametrul uChar specifică codul caracterelor în format pe un singur octet sau în codificare Unicode (în funcție de utilizarea versiunii Unicode a acestei funcții) Parametrul uFormat controlează practic formatul datelor solicitate de aplicație; valorile sale principale sunt enumerate în tabel Următorul parametru, Ipgm, indică o structură GLYPHMETRICS pentru a fi populată cu valorile glifului Pentru a obține un contur bitmap sau glif, o aplicație trebuie să treacă un pointer către un buffer IpvBuffer la funcția GetGlyphOutline; dimensiunea bufferului este setată de parametrul cbBuffer Ultimul parametru, pmat , indică către matricea de transformare afină în format fix Tabelul Format de rezultat GetGlyphOutline Descrierea valorii GGO METRICS Populați numai structura GLYPHMETRICS Returnați la succes, GDI ERROR la eșec GGO BITMAP Populați GLYPHMETRICS și bitmap la bit/pixel GGO NATIVE Populați GLYPHMETRICS și descrierea originală a glifului din fontul ThieType GGO BEZIER Completați GLYPHMETRICS și descrierea glifului ca curbe Bezier cubice GGO GRAY BITMAP Completați GLYPHMETRICS și bitmap de biți/pixel cu nivele de gri GG GRAY BITMAP Completați GLYPHMETRICS și bitmap de biți/pixel cu niveluri de gri GG GRAY BITMAP Completați GLYPHMETRICS și bitmap de biți/pixel cu de niveluri de gri Parametrul GGO GLYPH INDEX uChar conține index glif în loc de cod de caractere GGO UNHINTED Dezactivează instrucțiunile de procesare (sugestii) pentru contururile glifurilor (GGO NATIVE sau GGO BEZIER) Acceptat numai pe Windows Valorile glifului sunt returnate într-o structură GLYPHMETRICS care descrie un glif individual în sistemul de coordonate logic al contextului dispozitivului curent Câmpurile gmBlackBoxX și gmBlackBoxY definesc lățimea și înălțimea casetei de delimitare a glifului (și lățimea și înălțimea bitmap-ului returnat) Rețineți că acest dreptunghi este de obicei mai mic decât dreptunghiul celulei simbol Câmpul gmptGlyphOrigin conține o structură POINT care specifică coordonatele colțului din stânga sus al casetei de delimitare a glifului în raport cu acest Ieșire de text non-trivială punct pubian Rețineți că atunci când descrieți un glif TrueType în coordonate em-pătrat, axa verticală este de jos în sus, opusă direcției axei verticale în sistemul de coordonate al dispozitivului sau sistemul de coordonate logic în modul MM TEXT Câmpurile gmCellIncX și gmCellIncY definesc decalajul punctului de referință Bitmap glif Funcția GetGl yphOutl i ne poate returna un bitmap glif într-unul din cele patru formate Formatul GGO BITMAP este destinat celor mai simple rastere monocrome, în care corespunde pixelilor de fundal și pixelilor principali În celelalte trei formate, rasterul este returnat ca biți/pixel cu cantități diferite de tonuri de gri Aceste bitmap-uri sunt folosite de GDI pentru a afișa caractere netezite (în loc de tranzițiile obișnuite de hard edge) Pentru a afișa text cu caractere antialiased, este suficient să setați calitatea la ANTIALIASED QUALITY atunci când creați un font logic Cele trei formate de bitmap în tonuri de gri, GGO GRAY BITMAP, GG GRAY BITMAP și GG GRAY BITMAP, utilizează , și, respectiv, de niveluri de gri Probabil ar fi mai logic să apelați formatul GG GRAY BITMAP GG GRAY BITMAP Rasterele de glif sunt fie monocrome, fie biți/pixel Fiecare linie de scanare este întotdeauna aliniată cu două cuvinte, cu liniile de scanare din buffer returnate de GDI în ordine standard (de sus în jos) Astfel, formatul de bitmap pentru glif este exact același cu formatul de matrice de pixeli al unui bitmap DIB de comandă directă de sau biți Rasterul glif este de dimensiuni variabile, astfel încât o aplicație apelează mai întâi funcția GetGlyphOutline pentru a obține dimensiunea rasterului, alocă un bloc suficient de memorie și apelează funcția a doua oară pentru a obține datele raster Structura MAT definește o transformare afină mărginită pe plan Matricea de transformare conține numere cu virgulă fixă în formatul O transformare afină completă este descrisă de o structură XFORM care conține șase câmpuri reale: eMP, eM , eDx, eM , eM și eDy și vă permite să efectuați translație, scalare, oglindire, rotație, translație și combinațiile lor arbitrare Structura MAT elimină eDx și eDy din structura XFORM și convertește câmpurile rămase în format fix Astfel, structura MAT vă permite să descrieți scalarea, rotațiile, deplasările și reflexiile, dar nu și deplasările Având în vedere că offset-ul este ușor de implementat la ieșirea unui raster glif, funcția GetGlyphOutline acceptă de fapt transformări afine complete Vă rugăm să rețineți: este necesar parametrul MAT Chiar dacă transformarea este identică, trebuie să treceți într-o structură MAT completată corespunzător Odată ce aveți un bitmap glif, îl puteți converti într-un bitmap dependent de dispozitiv sau independent de dispozitiv și puteți utiliza funcțiile de bitmap GDI pentru a-l afișa Opțiunea DIB este preferată deoarece nu necesită crearea de noi obiecte GDI și facilitează gestionarea tabelului de culori pentru glifele anti-alias Funcția GetGlyphOutline permite aplicației să simuleze textul pe cont propriu, astfel încât aplicația se deschide înainte de Capitolul multe posibilități interesante Cu toate acestea, obținerea rasterelor glifelor și afișarea lor nu este o sarcină ușoară Lista arată declarația clasei KGlyph pentru lucrul cu rastere glif, încapsulând GetGlyphOutl i ne și simulând ieșirea unui singur caracter folosind GDI Implementarea completă a clasei KGlyph este pe CD Lista Clasa KGlyph: lucrul cu rasterele glif clasa KGlyph { public: GLYPHMETRICS mjnetrics: BYTE * m pPixeli; DWORD m nAl ocSize m nDataSize; int mjjFormat; KGlyphO: -KGlyph (gol): DWORD GetGlyph(HDC hDC UINT uChar UINT uFormat, const MAT * pMat =NULL); BOOL DrawGlyphROP(HDC HDC int x int y DWORD rop, COLORREF crBack COLORREF crFore); BOOL DrawGlyph(HDC HDC int x int y int & dx int & dy); }• Clasa KGlyph conține patru variabile principale: structura GLYPHMETRICS, buffer-ul bitmap pentru glif, dimensiunea tamponului și steag-ul de format Constructorul este destul de simplu; destructorul eliberează toată memoria alocată Metoda GetGlyph este un wrapper pentru apelarea funcției GetGlyphOutline În comparație cu GetGlyphOutline, nu primește o structură de metrică a glifului și un buffer, deoarece aceste date sunt gestionate de clasă, iar parametrul MAT este opțional, deoarece matricea de identitate este ușor construită în aplicație KGlyph::GetGlyph creează o matrice implicită, interogează dimensiunea datelor, alocă memorie și interogează datele glifului O funcție este utilizată pentru a obține valorile, rasterul și conturul glifului Metoda DrawGlyphROP desenează rasterul glifului returnat de metoda GetGlyphOutline cu culorile specificate (prim-plan și fundal) și operația raster Culorile de prim plan și de fundal imită atributele contextului dispozitivului GDI Operația bitmap simulează un mod de umplere a fundalului (transparent sau opac) sau orice alt mod de ieșire exotic la alegere Funcția DrawGlyphROP verifică formatul unui raster determinând formatul (biți/pixel) și numărul de niveluri de gri Pe baza datelor primite, se construiește un tabel de culori care conține doar culorile de prim-plan și de fundal sau nuanțe de gri situate între ele și calculate prin metoda interpolării liniare O structură BITMAPINFO este creată pe stiva pentru linia de scanare directă DIB, după care bitmap-ul glif este scos de funcția StretchDIBits cu operația de bitmap dată Rețineți că câmpul de înălțime din structura BITMAPINFOHEADER are semnul opus înălțimii dreptei de delimitare Ieșire de text non-trivială glif pătrat; făcând acest lucru, îi spunem GDI că liniile de scanare ale rasterului sunt în ordine înainte (în loc de ordinea inversă tradițională) Metoda DrawGlyph, bazată pe DrawGlyphROP, simulează operații auxiliare la desenarea unui raster Apelul funcției ar trebui să folosească modul de aliniere TA LEFT | TA BASELINE Metoda verifică dacă modul de umplere a fundalului a fost setat la opac în contextul dispozitivului În acest caz, zona în care este redat gliful este umplută cu culoarea de fundal După crearea unei pensule a cărei culoare este determinată de culoarea curentă a textului, bitmap-ul glifului este redat în mod transparent utilizând operația de bitmap ternar xE Amintiți-vă ce înseamnă codul de operare raster fără nume xE : dacă pixelul sursă este , utilizați culoarea pensulei; în caz contrar, receptorul rămâne neschimbat În acest caz, operația bitmap desenează pixelii din prim-plan cu culoarea textului curent (folosind o pensulă) și nu modifică pixelii de fundal Deoarece funcția DrawGlyph trebuia să fie cât mai generică posibil, nu a fost posibil să se folosească o operațiune SRCCOPY simplă pentru a desena glife individuale — dacă această funcție este apelată de mai multe ori consecutiv în desenarea unui șir, caseta de delimitare a glifului s-ar putea suprapune cu glifele anterioare casetă de încadrare Acest lucru face ca funcția DrawGlyph să folosească o operație transparentă de bitmap atunci când desenează bitmap de glif Când apelați DrawGlyph, nu este recomandat să utilizați modul de umplere a fundalului opac dacă funcția desenează mai mult de un caracter Fundalul textului trebuie redat la nivel de linie înainte ca primul glif să fie randat Funcția ajustează coordonatele ecranului în funcție de coordonatele punctului de bază al glifului din structura GLYPHMETRICS și desenează rasterul folosind metoda DrawGlyphROP Folosirea clasei KGlyph pentru a obține informații și a afișa hărți de biți pentru glif este ușoară și convenabilă Următorul exemplu simplu compară un șir redat de GDI cu șiruri de glife în diferite formate de bitmap void Demo GlyphOutl ne(HDC hDC) ( KLogFont f(-PolntSizetoLogical(hDC, ), „Times New Roman”): If mjf lfltalic = TRUE: If mJf lfQuality - ANTIALIASED QUALITY; Font KGDIObject(hDC, If CreateFontO): int x = : int y = : int dx, dy: SetTextAlign(hDC TA BASELINE | TA LEFT): SetBkColor(hDC, RGB( xFF, OxFF, )): // galben SetTextColor(hDC, RGB( , , OxFF)): // albastru // SetBkMode(hDC, TRANSPARENT): glif KGlyph; Capitolul TextOutChDC, x, y „ ” ); y+= ; glyph GetGlyph(hDC, 'G, GGO BITMAP); glif DrawGlyph(hDC, x, y, dx, dy);x+=dx; glyph GetGlyph(hDC, ' ', GG GRAY BITMAP); glif DrawGlyph(hDC, x, y dx, dy); x+=dx; glif GetGlyphChDC, * ' GG GRAY BITMAP); glif DrawGlyph(hDC, x, y, dx, dy); x+=dx; glif GetGlyphChDC, „ ” GG GRAY BITMAP); glif DrawGlyph(hDC, x, y, dx, dy); x+=dx; Funcția creează un font logic ditherat, scoate șirul „ ” cu funcția TextOut GDI și apoi emite cele patru glife separate „ ”, „ ”, „ ” și „ ” în formatele GGO BITMAP, GG GRAY BITMAP, GG GRAY BITMAP și GG GRAY BITMAP Rezultatul este prezentat în fig Orez Ieșire raster a glifelor generate de funcția GetGlyphOutline În stânga sus este un șir redat de GDL Pe plan intern, GDI pare să folosească formatul GG GRAY BITMAP cu niveluri de gri În stânga jos arată rezultatul rezultat de funcția KGlyph Poți vedea clar „crețurile” numărului „ ”, afișate în format GGO BITMAP, dar celelalte trei formate practic nu diferă unele de altele În dreapta, sunt afișate fragmente de raster cu glif cu și de niveluri de gri O analiză atentă a versiunii color a imaginii arată că pentru calcularea nuanțelor intermediare, GDI nu se limitează la interpolarea liniară în spațiul de culoare RGB Culorile folosite de GDI oferă un rezultat mai frumos, mai colorat decât cel implementat în Listarea Ieșire de text non-trivială conturul glifului Funcția GetGlyphOutline poate returna, de asemenea, o descriere a conturului glifului ca o combinație de linii și curbe Bezier care se potrivește cu descrierea originală a glifului într-un font TrueType Aplicația are noi capabilități de nivel scăzut pentru a lucra cu date care sunt foarte apropiate de descrierea fizică a unui font TrueType Utilizarea contururilor în loc de hărți de bit are multe utilizări interesante Cele trei steaguri ale parametrului uFormat determină formatul conturului glifului Formatul general este o secvență de așa-numitele poligoane TrueType Un poligon TrueType începe cu o structură TTPOLYGONHEADER urmată de o serie de structuri TTPOLYCURVE Dacă formatul este GGO NATIVE, poligoane TrueType constau numai din linii drepte și curbe Bezier pătratice O curbă Bezier pătratică este definită de trei puncte - două puncte finale și un control, în timp ce o curbă Bezier cubică este definită de patru puncte După cum am văzut în Capitolul , conturul unui glif în fonturile fizice TrueType este descris de un set codificat de linii și curbe Bézier pătratice, cu instrucțiuni pentru potrivirea la o grilă Astfel, ar fi greșit să spunem că formatul GGO NATIVE este pe deplin în concordanță cu descrierea glifului TrueType; cu toate acestea, este mult mai convenabil să lucrezi cu el în aplicații decât cu tabelele de glife fizice Dacă formatul de ieșire este GGOBEZIER, toate curbele Bezier pătratice din poligoane TrueType sunt convertite în cubice În mod implicit, calea rezultată suferă o procesare suplimentară - i se aplică instrucțiuni speciale, îmbunătățind aspectul glifului și asigurând consistența stilului grafic la dimensiuni mici ale fontului Dar dacă semnalul GGO NATIVE sau GGO BEZIER este setat în combinație cu GGO UNHINTED, instrucțiunile nu se aplică Conturul glifului returnat de GetGlyphOutline este scalat la dimensiunea curentă a fontului folosind o matrice de transformare Indiferent ce spune documentația, conturul glifului nu este returnat în unitățile folosite pentru a-l construi, iar matricea de transformare nu este ignorată Coordonatele punctelor din traseele glifului sunt returnate ca numere de înaltă precizie în virgulă fixă de de biți (întreg cu semn de biți și fracțional de biți) Din fericire, aceste coordonate reale sunt generate direct din descrierea glifului în fontul TrueType și nu sunt convertite în sistemul de coordonate al dispozitivului Puteți chiar să le aplicați transformări singur, fără să vă faceți griji cu privire la pierderea preciziei Următoarele sunt definițiile poligoanelor TrueType typedef struct tagPOINTFX { FIX x; FIX y; } POINTFX FAR*LPPOINTFX: typedef struct tagTTPOLYCURVE { WORD wType; WORD cpfx: POINTFX apfxEU; Capitolul } TTPOLYCURVE, FAR* LPTTPOLYCURVE: typedef struct tagTTPOLYGONHEADER { DWORD cb; DWORD dwType; POINTFX pfxStart; }TTPOLYGONHEADER FAR*LPTTPOLYGONHEADER; Conturul glifului este returnat ca un bloc de date umplut cu o secvență de poligoane TrueType Numărul de poligoane nu este specificat în mod explicit nicăieri, deși dimensiunea blocului de date este cunoscută Fiecare poligon TrueType corespunde unei căi închise în descrierea glifului Structura de date este variabilă ca dimensiune și începe cu o structură TTPOLYHEADER urmată de o serie de structuri TTPOLYCURVE Câmpul cb al structurii TTPOLYGONHEADER conține dimensiunea poligonului TrueType, câmpul dwType stochează tipul acestuia (singura valoare validă este TT POLYGON TYPE), iar câmpul pfxStart specifică punctul de început/sfârșit al poligonului Câmpul pfxStart poate fi considerat ca un fel de omolog al funcției MoveTo GDI Structura TTPOLYCURVE are o dimensiune variabilă și conține informații despre punctele cpfx Poate fi unul din trei tipuri (câmp wType) Dacă câmpul wType este egal cu TT PRIM LINE, structura descrie o polilinie; valoarea TT PRIM QSPLINE corespunde unei curbe Bezier pătratice, iar valoarea TT PRIM CSPLINE corespunde unei curbe Bezier cubice O linie întreruptă poate fi considerată ca o secvență de comenzi LineTo GDI O curbă Bezier cubică este întotdeauna formată din N x puncte, în GDI omologul său este comanda PolyBezierTo În cel mai simplu caz, o curbă Bézier pătratică este definită de două puncte; împreună cu ultimul punct al poligonului formează un segment de curbă În general, toate, cu excepția ultimului punct din curbele TT PRIM QSPLINE, sunt interpretate ca puncte de control Dacă mai multe puncte de control sunt consecutive într-o definiție de curbă, punctele finale suplimentare sunt inserate între fiecare pereche Cu toate acestea, acest subiect a fost discutat în Capitolul când a fost descris formatul glifului TrueType Principala problemă cu descifrarea unui poligon TrueType este iterarea peste segmente și convertirea lor în linii sau curbe Bezier pătratice acceptate de GDI GDI are o funcție PolyDraw care desenează o serie de curbe Bezier linie și cubice reprezentate de două tablouri Matricea POINT stochează coordonatele, iar matricea BYTE stochează steagurile Dacă am putea decoda conturul glifului într-o astfel de structură, atunci aplicația l-ar putea scoate cu un singur apel de funcție GDI Lista arată declarația clasei KG yphOutl i ne pentru decodarea și ieșirea contururilor de glif Implementarea completă a clasei se află pe CD-ul inclus Lista Clasa KGIyphOutline: lucrul cu contururi de glif șablon clasa KGIyphOutline public: POINT m Point[MAX POINTS]; BYTE m Flag[MAX POINTS]: Ieșire de text non-trivială Int m nPuncte: privat: void AddPoint(int x, int y, steag BYTE): void AddQSpline(int xl, int yl, int x , int y ): void AddCSpline(int xl, int yl, int x , int y , int x , int y ): void MarkLast (steagul BYTE): void Transform (int dx, int dy): public c: int DecodeTTPolygon(const TTPOLYGONHEADER * IpHeader, dimensiune int): BOOL Draw(HDC hDC, int x, int y): int DecodeOutline(KGlyph și glif) }: Variabilele clasei KGlyphOutline corespund parametrilor funcției PolyDraw - aceasta este o matrice de POINT, o matrice de BYTE și numărul de puncte Metoda AddPoint adaugă un punct nou cu un steag care specifică tipul acestuia Metoda AddCSpline adaugă o curbă Bezier cubică cu trei puncte Metoda AddQSpline convertește o curbă Bezier pătratică într-una cubică și apelează AddCSpline Metoda MarkLast este folosită doar pentru a marca ultimul punct care închide forma Coordonatele KGlyphOutline, date mai întâi ca numere cu punct fix, sunt stocate ca numere întregi de de biți, deoarece structura originală FIXED este greoaie de lucrat Metoda Transform convertește un număr cu virgulă fixă într-un număr întreg și adaugă un offset de pornire Puteți implementa cu ușurință transformări suplimentare - de exemplu, pentru a scala sau a roti toate punctele Metoda DecodeTTPolygon controlează decodarea datelor primite de funcția GetGlyphOutline Iterează asupra conținutului structurilor, inserează puncte de control implicite pentru curbele Bézier pătratice și apelează trei funcții auxiliare pentru a trasa curbele Fiecare poligon PT CLOSEFIGURE este marcat ca închis cu indicatorul PT CLOSEFIGURE Acest lucru asigură că liniile sunt completate corect atunci când utilizați un stilou geometric gros Listarea pare mai simplă decât codul de decriptare a datelor ThieType descris în Capitolul , deoarece cea mai grea parte a conversiei - decodificarea datelor de nivel scăzut ThieType, transformarea și rețeaua de rețea - este realizată de drivere de font, drivere de dispozitiv grafic și GDI Următorul fragment desenează un șir de text ca un contur folosind clasa KGlyphOutline Rezultatele apelurilor către OutlineTextOut și funcția TextOut GDI sunt prezentate în fig BOOL OutlineTextOut(HDC hDC, int x int y, const TCHAR * str, int count) { dacă (număr schiță: în timp ce (număr > ) Capitolul if ( glyph GetGlyphthDC * str GGO NATIVE)> ) if ( outline DecodeOutline(glyph) ) outline Draw(hDC, x, y): x += glyph mjnetrics gmCellIncX: Y += glyph mjnetrics gmCellIncY: str++; numara returnează TRUE: contur Orez Ieșire contur text folosind GetGlyphOutline Formatarea textului În acest capitol, am analizat cea mai simplă ieșire de text (funcția TextOut), ieșirea mai complexă la nivelul indicilor de glif și poziționarea caracterelor individuale (funcția ExtTextOut) și chiar operațiunile de nivel scăzut cu hărți de biți și contururi de glife folosind funcția GetGl yphOutl ne Pe scurt, am acoperit aproape tot ce trebuie să știți despre textul în GDI Este timpul să vedem cum sunt puse în practică aceste caracteristici (cu excepția cazului în care, desigur, preferați să lucrați la nivel de tabel TrueType - despre care a fost discutat în Capitolul ) Această secțiune tratează tot felul de probleme legate de formatarea textului, adică de plasarea caracterelor în conformitate cu cerințele date Ieșire text cu file Filele sunt utilizate pe scară largă în editorii de text simple pentru a alinia textul în coloane, facilitând citirea datelor Cu toate acestea, ta- Formatarea textului ieșirea textului îngrădit este folosită și în multe pachete moderne GDI conține funcții speciale pentru obținerea de valori și pentru afișarea șirurilor de text care conțin caractere de tabulatură interne LONG TabbedTextOut(HDC hDC int x int y LPCTSTR IpString int nCount int nTabPosition LPINT IpnTabStopPositions int nTabOrigin): DWORD GetTabbedTextExtent(HDC hDC LPCTSTR IpString int nCount int nTabPosition LPINT IpnTabStopPositions): În comparație cu TextOut, funcția TabbedTextOut primește trei parametri noi Matricea specificată de parametrii IpnTabStopPositions și nCount stochează coordonatele orizontale secvențiale ale punctelor de tabulare Parametrul nTabOrigin conține decalajul de adăugat la toate punctele de tabulare Dacă matricea stochează coordonatele de poziție relativă, nTabOrigin specifică punctul de pornire pentru numărarea pozițiilor filelor, astfel încât matricea să nu mai fie dependentă de o anumită poziție de ieșire Dacă șirul de ieșire conține caractere tabulatoare (\t), GDI imprimă începutul liniei până când întâlnește un caracter tabulator Pentru a face acest lucru, GDI scanează tabelul de tabulaturi, găsește cea mai apropiată poziție a filei în el și continuă să scoată text din acea poziție Acest lucru se repetă până când întreaga linie a fost imprimată Dacă numărul de caractere de tabulație dintr-o linie depășește numărul de intrări din tabel, GDI calculează puncte de tabulație suplimentare pe baza ultimei date Cu alte cuvinte, dacă doriți să utilizați tabulaturi echidistante, este suficient să treceți o matrice de un element Rețineți că funcția nu garantează că caracterele de după caracterul i-a de filă vor fi afișate în poziția i-a În schimb, GDI caută în tabel următoarea tabulatură cea mai apropiată de poziția curentă din text Tab stopurile pot fi negative; în acest caz, GDI aliniază textul la dreapta înainte de poziția dată, în loc să îl alinieze la stânga după acesta Funcția TabbedTextOut returnează un număr de de biți al cărui cuvânt înalt este înălțimea și cuvântul scăzut este lățimea șirului Ambele valori sunt date în coordonate logice Funcția GetTabbedTextExtents returnează dimensiunile textului cu file fără a-l afișa Un exemplu simplu de utilizare a TabbedTextOut pentru a afișa text în coloane folosind file int tabstop[] = { - , }: const TCHAR * linesEJ » { „Grup” „\t” „Rezultat” „\t” „Funcție” „\t” „Parametri” „\t” „(HDC hDC )” „\t” „(HDC hDC )" „Font” „\t” „DWORD” „Text” „\t” „BOOL” }: „\t” „GetFontData” „\t” „TextOut” int x= y= ; pentru (int i= : i stânga = x + min(abc abcA ); pRect->dreapta = x + abc abcA + abc abcB + max(abc abcC ); pRect->top = y; pRect->jos = y + înălțime; returnează TRUE; } BOOL ColorText(HDC hDC int x int y LPCTSTR pString int nCount HBRUSH hFore) { HGDIOBJ hold = SelectObject(hDC hFore); RECT rect; GetOpaqueBox(hDC, pString nCount, & rect x y); Continuare Capitolul Lista Continuare PatBlt(hDC, rect stânga rect sus rect dreapta-rect stânga, rect bottom - rect top PATINVERT): int oldBk = SetBkMode(hDC TRANSPARENT): COLORREF oldColor = SetTextColor(hDC RGB( , )); TextOut(hDC xy pString nCount): SetBkModeChDC oldBk): SetTextColor(hDC oldColor): BOOL rslt = PatBlt(hDC rect left rect top, rect right-rect stânga rect bottom - rect top PATINVERT): SelectObject(hDC, Hold): returnează rslt: } Funcția GetOpaqueBox verifică metrica A a primului caracter și metrica C a ultimului caracter pentru a vedea dacă sunt negative Pentru verificare, este utilizată funcția GetTextABCExtent descrisă în acest capitol În plus, luăm în considerare diferite combinații de steaguri de aliniere verticală și orizontală și facem ajustări adecvate parametrilor dreptunghiului Funcția ColorText pictează un dreptunghi de două ori folosind funcția PatBlt cu operația de bitmap PATINVERT Înainte ca textul să fie afișat, modul de umplere a fundalului și culoarea textului trebuie setate corect și restabilite la valorile inițiale după finalizare Pe fig Figura prezintă exemple de utilizare a funcțiilor GrayString, ColorText și BitmapText Orez Colorarea textului cu funcțiile GrayString, ColorText și BitmapText Există trei operațiuni de trasare implicate în funcțiile ColorText și BitmapText și există o pâlpâire urâtă când desenați direct în contextul dispozitivului de pe ecran Problema este rezolvată prin memorarea în cache a ieșirii într-un context de dispozitiv intermediar sau folosind alte trucuri care nu necesită desene multiple Vă rugăm să rețineți că, datorită utilizării Efecte de ieșire a textului Netezirea fonturilor nu este recomandată pentru operațiuni, deoarece pixelii de culori destul de ciudate vor apărea în imagine Inscripții Când creează un font logic, o aplicație poate selecta diferite greutăți (greutate, cursiv, dither, subliniere și baraj) folosind atributele structurii LOGFONT O familie de fonturi TrueType constă de obicei din patru fișiere fizice care acceptă patru greutăți: obișnuit, aldine, cursive și cursive aldine Sistemul compară cerințele utilizatorului cu atributele fonturilor instalate și găsește cea mai bună potrivire Dacă un font cu greutatea specificată nu este disponibil, GDI încearcă să-l sintetizeze în cel mai simplu mod posibil (doar dacă fontul disponibil are greutate normală și fontul solicitat este aldine) Imitația este atât de simplă încât diferențele sunt vizibile doar la o dimensiune mică a fontului - GDI pur și simplu scoate linia de două ori cu un offset orizontal de un pixel Dacă aveți doar un font aldine, GDI nu va putea sintetiza un font obișnuit din acesta Fonturile italice sunt mult mai ușor de sintetizat După cum sa menționat mai sus, ultimul parametru al funcției GetGlyphOutline definește o matrice de transformare x , care permite tăierea glifului Imitația italice se reduce la o ușoară schimbare pentru a ține seama de schimbarea valorilor fontului La descrierea funcției GetGlyphOutline, a fost menționată și anti-aliasingul suportat de driverele de font GDI folosește hărți de bit glif cu niveluri de gri pentru a netezi textul Pentru a solicita anti-aliasing pentru un font TrueType, treceți indicatorul ANTIALIASED QUALITY în câmpul de calitate; contextul dispozitivului trebuie să fie setat la High Color sau True Color Sublinierea și bararea sunt implementate de GDI pe baza datelor conținute în structura OUTLINETEXTMETRIC a fontului TrueType Unele aplicații acceptă stiluri diferite de subliniere și baraj, dar toate sunt sintetizate din aceleași date Pe lângă efectele suportate la nivel de font logic, în aplicații sunt adesea implementate și alte efecte de text - ieșire negativă, umbre, relief (în relief și îngroșat), linii de contur etc Ieșirea negativă este implementată cu ușurință - doar schimbați culoarea textului cu culoarea de fundal și afișați textul într-un mod opac Pentru a reproduce cu acuratețe efectele umbrelor și reliefului, trebuie să lucrați la nivel raster și să modelați sursele de lumină În editorii de text, se folosește de obicei o abordare simplificată - aceeași linie este afișată de mai multe ori cu decalaje și culori diferite Funcția OffsetTextOut scoate un șir de text de până la trei ori Primii cinci parametri sunt similari cu cei ai funcției TextOut Următoarele două grupuri de trei parametri specifică șirurile offset și îmbrăcate pentru re-ieșire În primul rând, funcția emite prima linie de offset cu parametri (x + dxl,y + dyl,crtl), apoi a doua linie de offset cu parametri (x + dx ,y + dy ,crt ), după care Capitolul scoate șirul original din punctul (x, y) cu culoarea textului original Programul desenează un dreptunghi mărit, iar cele două linii offset sunt desenate în modul transparent BOOL OffsetTextOut(HDC hDC, int x, int y LPCTSTR pStr, int nCount, int dxl, int dyl, COLORREF cri, int dx , int dy , COLORREF cr ) COLORREF cr = GetTextColor(hDC): int bk = GetBkMode(hDC): Dacă (bk==OPAC) { RECT rect: GetOpaqueBox(hDC, pStr, nCount, & rect, x, y); rect stânga += min(min(dxl, dx ), ): rect dreapta += max(max(dxl, dx ) ): rect top += min(min(dyl, dy ), ): rect bottom+= max(max(dyl, dy ) ): ExtTextOut(hDC, x, y, ETO OPAQUE & rect, NULL NULL): } SetBkMode(hDC, TRANSPARENT): dacă ( (dxl!= ) || (dylHO) ) { SetTextColor(hDC, cri): TextOut(hDC, x + dxl, y + dyl, pStr, nCount): } dacă ( (dxl!= ) || (dyl!= ) ) { SetTextColor(hdc cr ): TextOut(hDC, x + dx , y + dy , pStr, nCount): SetTextColor(hDC, cr): BOOL rslt = TextOut(hDC, x, y, pStr, nCount): SetBkMode(hDC bk): return rslt: } Următorul fragment arată modul în care funcția OffsetTextOut creează efecte de umbră, de relief și de relief // Umbra SetBkColorChDC RGBCOxFF, OxFF, )): // Fundal galben SetTextColor(hDC, RGB( , , OxFF)): // Text albastru OffsetTextOut(hDC, x, y, „Umbră”, , , , GetSysColor(C L R DSHAD W), // Shadow ): Efecte de ieșire a textului // Ușurare ridicată SetBkColor(hDC, RGBCOxDO, OxDO, )): // Fundal galben închis SetTextColorChDC, RGBCOxFF, OxFF, )); // Text galben OffsetTextOut(hDC, x, y „Relief”, , -unsprezece GetSysColor(COLOR DLIGHT), , GetSysColor(COLOR J DDKSHADOW)): // Relief încastrat SetBkColor(hDC, RGB( xFF, OxFF )): // Fundal galben SetTextColorChDC, RGB( xD , OxDO, )); // Text galben închis OffsetTextOutChDC, x, y, „gravează”, , - , - , GetSysColor(C L R DDKSHAD W), , , GetSysColor(C L R DLIGHT)): Umbra este simulată prin previzualizarea textului gri la un offset de ( , ) Pentru a crea un efect de relief în relief, textul mai deschis la un decalaj de (- , - ) este afișat mai întâi, iar apoi textul mai întunecat la un decalaj de ( , ) Efectul de relief încastrat este simulat în același mod, doar culorile sunt inversate Offset-urile utilizate în acest exemplu sunt potrivite numai pentru afișarea obișnuită Când ieșirea este mărită sau tipărită pe o imprimantă, acestea trebuie ajustate în consecință Pe fig Figura prezintă diferite opțiuni de stil de text: obișnuit, aldin, anti-alias, cursiv, cursiv aldin, subliniat, barat, negativ, umbră, relief ridicat și îngroșat Stil Stil Umbră Stil Stil stil Orez Stiluri de text efecte geometrice Până acum, am considerat doar textul proporțional afișat vertical Este timpul să vă familiarizați cu ieșirea textului cu orientare și unghi diferit de rotație a caracterelor, cu distorsiunea proporțiilor originale etc Capitolul Structura LOGFONT conține două atribute legate de unghiul de ieșire a textului Câmpul IfEscapement setează unghiul liniei de bază pentru întregul șir, în timp ce câmpul IfOrlentatlon setează unghiul liniei de bază pentru caracterele individuale În arhitectura GDI, aceste unghiuri pot diferi De exemplu, un șir poate fi afișat orizontal (IfEscapement = ), dar fiecare caracter din acesta poate fi rotit cu ° Cu toate acestea, detectarea independentă a unghiului este acceptată numai în modul grafic avansat și, prin urmare, este disponibilă numai în Windows NT/ În modul grafic compatibil, câmpul fEscape definește ambele colțuri Unghiurile sunt date ca numere întregi în zecimi de grad Pentru majoritatea aplicațiilor, această precizie este suficientă Valorile unghiurilor dorite sunt introduse în structura LOGFONT înainte ca fontul logic să fie creat Acest lucru nu este dificil de făcut, dar cu modificări frecvente ale unghiurilor în funcția de ieșire, o astfel de soluție se dovedește a fi supărătoare și incomodă O altă abordare este de a păstra același font logic și de a defini o transformare diferită a lumii cu rotația sistemului de coordonate logic Una dintre cele mai interesante utilizări ale textului înclinat este plasarea caracterelor de-a lungul unei curbe (o caracteristică acceptată de multe pachete grafice) În GDI, orice curbă poate fi convertită într-o cale de instrumente GDI prin împachetarea comenzilor grafice între apelurile la BeginPath și EndPath Traiectoria rezultată este convertită într-o polilinie de către funcția FlattenPath După aceea, puteți folosi funcția GetPath pentru a obține toate punctele care definesc calea (operațiile cu linii și curbe sunt descrise în detaliu în Capitolul ) Având o matrice cu date de traiectorie, puteți obține offset-ul unui singur simbol și puteți calcula coordonatele segmentului de polilinie corespunzător Din coordonatele segmentului (x ,y ) - (x^yj , se calculează punctul de ieșire și unghiul caracterului Lista prezintă un grup de funcții pentru plasarea textului de-a lungul curbei definite de calea curentă în dispozitiv context Lista Plasarea textului de-a lungul unei căi dublu dis(dublu xO, dublu yO dublu xl dublu yl) xl -= xO; yl -= yO: returnează sqrt( xl * xl + yl * yl ): const dublu pi = , : BOOL DrawChar(HDC hDC dublu xO, dublu yO dublu xl, dublu yl tcharch) { xl -= xO: yl -= yO: int escape = : dacă ( (xKO Ol) && (xl>- , ) ) dacă ( yl> ) escape= : Efecte de ieșire a textului altfel evacuare= ; altfel { unghi dublu = atan(-yl/xl); scăpare = (int) ( unghi * / pi * + , ); } LOGFONTlf; GetObject(GetCurrentObject(hDC, OBJ FONT), sizeof(lf), &lf); if ( lf IfEscapement != escapement ) { lf IfEscapement = evacuare; HFONT hFont = CreateFontIndirect(&lf): if (hFont==NULL) returnează FALSE: DeleteObject(SelectObject(hDC, hFont)); } TextOut(hDC, (int)xO, (int)yO, &ch, ); returnează TRUE; } void PathTextOut(HDC hDC, LPCTSTR pString, POINT point[], int nr) { dublu xO = punctul[ ] x; dublu yO = punctEO],y: pentru (int iel; i ) ( if ( glyph GetGlyph(hDC, * str GGO BITMAP)> ) glif DrawGlyphROP(hDC x + glyph mjnetrics gmptGlyphOrigin x y - glyph mjnetrics gmptGlyphOrigin y, rop, crBack, crFore): x += glyph m metrics gmCel IncX; y += glyph mjnetrics gmCellIncY; str++:count } returnează TRUE: } Funcțiile BitmapTextOut și BitmapTextOutROP mută sarcina din zona de text în zona bitmap Aceasta rezolvă problemele asociate cu reflectarea în oglindă în sistemul de coordonate logic și devine posibilă aplicarea operațiilor raster Cu toate acestea, trebuie să fiți atenți când utilizați operațiuni de bitmap pentru a reda hărți de biți pentru glif, deoarece pixelii de fundal ai diferitelor glife se pot suprapune la ieșirea unui șir Funcția BitmapTextOutROP selectează culoarea la care pixelii de fundal ar trebui să fie mapați pe baza culorii de fundal a contextului dispozitivului De exemplu, dacă doriți să utilizați operația SRCAND, alegeți o culoare de fundal albă (RGB( xFF,OxFF,OxFF)); în acest caz, pixelii de fundal nu vor afecta rezultatul Următorul fragment confirmă faptul că instrumentele GDI nu permit oglindirea textului și, de asemenea, ilustrează tehnica de oglindire a textului folosind funcția BitmapTextOut și aplicând operațiuni bitmap la ieșirea textului // Text în oglindă { SalvareDC(hDC): SetMapMode(hDC, MM ANISOTROPIC); SetW ndowExtEx(hDC, , NULL): SetViewportExtEx(hDC, - , - NULL): SetV ewportOrgEx(hDC, , , NULL); ShowAxes(hDC, , ): int x= , y= ; const TCHAR *mesaj = "Reflecție": Capitolul SetTextAlign(hDC, TA LEFT | TA BASELINE): SetTextColor(hDC, RGB(O, O, OxFF)); // Albastru (întunecat) BitmapTextOut(hDC, x, y, mess, tcslen(mess), GG GRAY BITMAP); SetTextColor(hDC, RGBCOxFF, OxFF, )); // Lumină galbenă) TextOut(hDC, x y, mess, tcslen(mess)); RestoreDC(hDC, - ); // Operații raster la afișarea textului int x = : int y = ; KLogFont f(-PointSizetoLogical(hDC, ), „Times New Roman”); lf m lf IfWeight = FW BOLD; f,m lf fQuality= CALITATE ANTIALIASED; Font KGDIObject(hDC, If CreateFontO); const TCHAR *message = "Raster"; SetBkColor(hDC, RGB( xFF, OxFF, OxFF)); SetTextColor(hDC, RGB( xFF, , )); BitmapTextOutROP(hDC, x, y, mess, tcslen(mess), SRCAND); SetBkColor(hDC RGB( , , )); SetTextColor(hDC, RGB( , OxFF, )); BitmapTextOutROP(hDC, x+ y+ , mess, tcslen(mess), SRCINVERT); Fragmentul începe prin setarea modului de afișare anizotrop, în care axa x este direcționată de la dreapta la stânga, iar axa y este de jos în sus Mai întâi scoatem text albastru (întunecat) cu funcția BitmapTextOut și apoi scoatem același șir în culoare galbenă (deschisă) cu funcția GDI TextOut Liniile sunt afișate în aceleași coordonate logice, dar după cum se poate vedea din Fig , acestea apar pe ecran în locuri diferite și cu orientări diferite Orez Efecte folosind hărți de bit glif Efecte de ieșire a textului Codul pentru a doua jumătate a fragmentului scoate o linie roșie folosind operația de bitmap SRCAND și apoi repetă același text în verde cu un offset de ( ) și operația de bitmap SRCINVERT Pentru a preveni ca pixelii de fundal să afecteze rezultatul, operațiunea SRCAND folosește o culoare de fundal albă, iar operația SRCINVERT folosește o culoare de fundal neagră Conversia textului în bitmap Dacă o aplicație dorește să proceseze datele bitmap înainte de a le reda într-un context de dispozitiv sau să le stocheze pentru o utilizare ulterioară, în loc să opereze pe glife individuale, este mai bine să rasterizezi întregul șir deodată Rasterului rezultat pot fi aplicați tot felul de algoritmi grafici - de exemplu, cei descriși în capitolele - ale acestei cărți Listarea arată declarația clasei KTextBitmap, care convertește un șir de text într-o secțiune DIB, cu un simplu filtru de estompare Clasa KTextBitmap combină diferitele tehnici de manipulare bitmap și text discutate în carte Implementarea completă este disponibilă pe CD-ul inclus Lista Clasa KTextBitmap: aplicarea efectelor bitmap textului // Convertiți un șir de text într-o clasă bitmap KTextBitmap { public: HBITMAP mJiBitmap; HDC mJiMemDC; HGDIOBJ mJiOldBmp; int m width; int mjielght; int m dx; int m dy; BYTE*m pB ts; BOOL Convert (HDC hDC LPCTSTR pString, int nCount, Int extra); void ReleaseBitmap(void): KTextBitmap(); ~KTextBitmap(); void Blur(gol); BOOL Draw(HDC hDC, Int x, int y Introp=SRCCOPY); }; Toată munca principală este realizată de clasa KTextBitmap: :Convert Clasa primește mânerul de context al dispozitivului, șirul, numărul de caractere și numărul de pixeli suplimentari de adăugat din cele patru margini ale bitmap-ului generat Spațiul suplimentar este utilizat atunci când rasterul este mărit ca urmare a aplicării algoritmilor grafici Funcția calculează dimensiunile hărții de biți din dimensiunile dreptunghiului text de fundal, creează o secțiune DIB de de biți, creează un context de dispozitiv compatibil și copiază atributele din contextul dispozitivului curent în contextul compatibil Locația textului în raster este ajustată în funcție de valoarea metricii A a primului caracter pentru a preveni posibila tăiere a unei părți din glif După finalizarea sub Capitolul șirul de gătit este scos la raster printr-un simplu apel la TextOut Metoda KTextBitmap::Convert este limitată la cea mai simplă conversie — funcționează numai cu contexte de dispozitiv în modul de mapare MM TEXT Pentru a demonstra capacitatea de a procesa text după ce a fost convertit într-un format bitmap, la clasa KTextBitmap a fost adăugată o metodă Blur, care, folosind modelul Average, aplică un filtru de medie x canalelor RGB ale unui - secțiunea bit DIB În partea de jos a Fig Figura ilustrează conversia text în raster și rezultatele estomparii În stânga este linia originală Linia de mijloc a fost estompată de două ori, iar linia dreaptă a fost filtrată de patru ori Partea inferioară a figurii arată efectul unei umbre neclare, neclare, obținută folosind clasa KTextBitmap - pentru aceasta, bitmap-ul trece printr-o procedură de estompare de ori KTextBitmap bmp; SetBkMode(hDC, OPAC): SetBkColor(hDC, RGB( xFF, OxFF, OxFF)): // Alb SetTextColor(hDC, RGB( x , x , x )): // Gri const TCHAR * mess = "Umbra moale"; bmp Convert(hDC, mizerie, tcslen(mizerie), ): pentru (int = ; i Type>=EMR MIN) && (emr->iType iType emr->nS ze); stream " mizerie; if ( emr->iType==EMR EOF ) pauză; emr = (const EMR *) ( ( const char * ) emr + emr->nSize ); } șterge[]pBuffer; return recunoaștere; Funcția DumpEMF iterează peste toate intrările EMF și trimite numărul, tipul și dimensiunea fiecărei intrări într-un flux de fișiere C++ Această funcție arată doar că trecerea în buclă a înregistrărilor ajută la înțelegerea structurii interne a EMF CD-ul include un parser EMF puternic implementat în clasa KEmfDC Această clasă vă permite să afișați conținutul EMF sub forma unui arbore ierarhic (TreeView) cu decodificarea intrărilor EMF în comenzi și parametri GDI Pe fig în stânga este decodarea comenzilor EMF, iar în dreapta este rezultatul redării EMF : G nBytesi — : nÎnregistrări: nManere: sRezervat: O • nDescriere: '■ offDescnpbon: nPalEntries: >• szIDevice: { } ; szIMilhmetre: { } : •• cbPixelFormat: ■■■■ offPixelFormat: ■■■■ bOpenGL: ; •• szMicfoMeters: { , } hOb|[ ]=CreateFont(- , , , , , , , , , , , ? =■ : SelectOb|ect(hDC, hOb|[ ]); octeți StretchDIBits(hDC, , , , , , , , SetBkModefhDC,OPAQUE), octeți SetBkColorfhDC, RGB( xFF, xFF, xFF)), octeți: •• : SetTextColorfhDC, RGB( , , )); octeți eu zhIDkhI Orez Decodarea și vizualizarea EMF în program Capitolul Metafișiere Figura reproduce un metafișier text în relief creat de unul dintre programele din Capitolul Un vizualizator și decodor EMF este inclus într-unul dintre exemplele din acest capitol Deschideți un fișier EMF pe disc sau inserați un EMF din clipboard - programul își va decripta înregistrările și le va reda În partea stângă a figurii, sunt vizibile o parte din antetul EMF și cinci comenzi GDI decodificate După cum indică titlul, metafișierul constă din de intrări, are o lungime de de octeți și este scris pentru un ecran de x pixeli Printre intrările EMF, vedem funcțiile de a crea un font logic, de a-l selecta în contextul dispozitivului, de a afișa bitmaps și de a seta culoarea de fundal/modul de umplere pentru ieșirea ulterioară Partea din dreapta a ferestrei arată rezultatul redării metafișierului la scară : Obiecte GDI simple în EMF EMF Viewer and Decryptor (vezi Figura ) este un instrument valoros pentru analiza metafișierelor și diagnosticarea problemelor cu acestea Să aruncăm o privire mai atentă asupra structurii EMF Doar patru tipuri de obiecte GDI — stilou logic, pensulă logică, font logic și paletă logică — sunt stocate în EMF ca obiecte GDI Funcțiile de creare pentru aceste tipuri de obiecte au o reprezentare similară în înregistrările EMR: lista de parametri începe cu un index în tabelul de manipulare EMF, urmat de o definiție logică a obiectului Ca exemplu, voi da structura înregistrării EMF pentru funcția CreatePen: typedef struct tagEMRCREATEPEN { EMR emr; // Antet standard DWORD IhPen: // Index în tabelul manipulatorilor LOGPEN lopn: // Definiție booleană } EMRCREATEPEN; Când se redă un EMF, GDI creează un mic tabel de ghidare al cărui număr de intrări este determinat de câmpul nHandles al intrării antetului EMF Indicele din intrarea EMRCREATEPEN se referă în mod specific la acest tabel de ghidare EMF, și nu la tabelul de obiecte GDI ascunse de sistem Prima intrare a tabelului de manipulare EMF este rezervată Tabelul este descris de structura HANDLETABLE typedef struct tagHANDLETABLE { HGDIOBJ objecthandleEl]; // Dimensiune variabilă, definită de nHandles } MANEBILĂ: Obiectele GDI standard nu sunt stocate în tabelul de manipulare EMF Pentru a face referire la un obiect standard, identificatorul acestuia este indicat cu un semn invers Obiectele GDI standard de la GetStock-Object(WHITE BRUSH) la GetStockObject(DC PEN) sunt documentate în prezent În GDI H, WHITE BRUSH este definit cu o valoare de și DC PEN este definit cu o valoare de , deci indicii lor sunt între și respectiv - Acest lucru explică și de ce este rezervat indicele din tabelul de manipulare EMF În EMF, intrările se referă adesea la pixuri logice, pensule, fonturi sau palete Din fig Figura arată că a doua intrare EMF creează un font logic și îl plasează în elementul al tabelului de manipulare EMF; a treia intrare EMF selectează obiectul referit în elementul în contextul dispozitivului Structura metafișierelor extinse Utilizarea unui simplu tabel de mâner EMF rezolvă cu grație problema naturii tranzitorii, nedeterministe a mânerelor de obiect GDI Cu toate acestea, convertirea mânerelor GDI în indexuri nu este atât de ușoară pe cât pare la prima vedere În primul rând, GDI nu poate înregistra pur și simplu o funcție de creare a obiectelor GDI, deoarece mânerul poate să nu fie folosit deloc în contextul dispozitivului de referință Înregistrarea creării obiectului este stocată în EMF doar prima dată când manipulatorul este folosit efectiv Aceasta înseamnă că de fiecare dată când vă referiți la un stilou, pensulă, paletă sau mâner de font GDI, trebuie să căutați tabelul mânerului EMF și să verificați dacă acel mâner a fost înregistrat anterior Când manipulatorul este utilizat pentru prima dată, GDI folosește funcția GetObject pentru a obține definiția prin care a fost creat manipulatorul și generează o înregistrare de creare a obiectului; în caz contrar, indicele este luat din tabel Funcția DeleteObject este stocată și în EMF cu tipul EMRDELETEOBJECT Desigur, acest lucru se întâmplă doar dacă manipulatorul a fost folosit efectiv După ce ați jucat EMF, pot exista elemente neșterse în tabelul cu mâner EMF GDI se asigură că tabelul este dealocat corespunzător; acest lucru împiedică obiectele GDI să scurgă redarea EMF din cauza erorilor de scriere Aplicația poate verifica numărul de mânere din tabel și poate afla care mânere au rămas în el după redare Acest lucru ajută și la combaterea scurgerilor de resurse Rastere în EMF GDI acceptă trei tipuri de rastere: rastere dependente de dispozitiv (DDB), rastere independente de dispozitiv (DIB) și secțiuni DIB Rasterele DIB nu sunt obiecte GDI în sensul că GDI nu gestionează stocarea lor de date, dar DDB-urile și secțiunile DIB sunt obiecte GDI Cu toate acestea, nu veți găsi înregistrări ale creării de obiecte DDB și secțiuni DIB în EMF DDB este în mod inerent specific dispozitivului și chiar specific dispozitivului Desigur, DDB nu poate fi stocat direct într-un metafișier extins, care trebuie să ofere o reprezentare independentă de dispozitiv a datelor grafice O altă problemă cu rasterele DDB este că nu pot fi redate direct într-un context de dispozitiv; pentru a lucra cu ele, trebuie să implicați un context de dispozitiv compatibil Poate acesta este motivul pentru care dezvoltatorii GDI nu au interpretat DDB-urile și secțiunile DIB din metafișiere extinse ca obiecte GDI În schimb, DDB-urile și secțiunile DIB sunt întotdeauna convertite în bitmap-uri DIB dezambalate În GDI, un bitmap DIB dezambalat este reprezentat de doi pointeri către o structură BITMAPINFO și către o matrice de pixeli În absența unui manipulator, nu este posibil să se facă referire la un raster într-un EMF; s-a decis ca datele raster să fie transmise împreună cu comenzile în care sunt utilizate Să vedem cum este codificată funcția BitBlt GDI în intrarea EMF EMRBITBLT typedef struct tabEMRBITBLT { EMR emr; Capitolul Metafișiere RECTL LONG rclBounds; xDest; // Setați în unități de dispozitiv LONG yDest; LONG cxDest; , LONG cyDest; DWORD dwRop; LONG xSrc; LONG ySrc; XFORM xformSrc; // Transformă contextul original al dispozitivului COLORREF crBkColorSrc; // Culoarea de fundal a contextului original al dispozitivului în RGB DWORD iUsageSrc: // Format tabel de culori bitmap // (DIB RGB COLORS) DWORD de f Bnri Src; // Offset al structurii BITMAPINFO DWORD cbBmISrc; // Dimensiunea structurii BITMAPINFO DWORD offBitsSrc; // Offset al datelor grafice ale rasterului DWORD cbBitsSrc; // Dimensiunea datelor grafice raster EMRBITBLT; Amintiți-vă că funcția BitBlt GDI ia nouă parametri: un mâner de context dispozitiv de recepție, patru parametri de poligon de recepție, un mâner de context dispozitiv sursă, un punct de bază în contextul sursă și o operație bitmap În structura EMRBITBLT, contextul dispozitivului receptor nu este necesar deoarece este definit indirect; dreptunghiul de destinație este reprezentat de quad {xDest, yDest, cxDest, cyDest}, punctul de bază al originii este reprezentat de câmpurile {xSrc, ySrc}, iar operația raster este specificată de câmpul dwRop Rămâne să ne ocupăm de manipulatorul de context sursă (și de opt câmpuri ale structurii EMRBITBLT) Sursa pentru un apel către BitBlt poate fi un context de dispozitiv compatibil cu rasterul DDB sau secțiunea DIB selectată sau un context de dispozitiv de ecran Este puțin probabil să fie un context de dispozitiv de imprimantă, deoarece contextele de imprimantă sunt de obicei ilizibile Un context de dispozitiv compatibil poate fi reprezentat de bitmap-ul pe care îl conține, iar un context de dispozitiv de ecran poate fi ușor convertit într-un bitmap format din pixelii săi actuali În ambele cazuri, sursa este convertită într-un raster DIB descris de ultimele câmpuri ale EMRBITBLT Câmpul iUsage oferă interpretarea tabelului de culori, câmpurile (offBmiSrc, cbBmi'Src) se referă la structura BITMAPINFO, iar câmpurile (offBitsSrc, cbBitsSrc) identifică matricea de pixeli Rezultatele unui apel către BitBlt pot fi, de asemenea, afectate de starea contextului original al dispozitivului Câmpul xformSrc stochează datele de mapare de la coordonatele logice la coordonatele dispozitivului Parametrul cbBkColorSrc specifică culoarea de fundal a contextului dispozitivului sursă care poate fi utilizată pentru a afișa hărți de biți color în contexte de dispozitiv monocrome Câmpul rc Bounds conține caseta de delimitare din sistemul de coordonate al dispozitivului de referință Desigur, acest dreptunghi poate fi calculat în timpul redării, dar stocarea lui în EMRBITBLT îmbunătățește oarecum performanța Toate rasterele din EMF sunt reprezentate de același model: steag format tabel de culori, umplutură de date BITMAPINFO și umplutură de matrice de pixeli Dezavantajul acestei reprezentări este că rasterul este salvat din nou de fiecare dată când este utilizat Dacă același raster este aplicat de de ori, Structura metafișierelor extinse va fi salvat de de ori în EMF Poate că pentru bitmapurile mici sau de unică folosință, acest lucru este încă suportabil, dar în pachetele grafice moderne care folosesc adesea umpleri bitmap, apar probleme serioase După cum a arătat experimentul pentru program, atunci când rasterul este re-ieșit în EMF, copia sa completă este inclusă Astfel, dimensiunea EMF crește proporțional cu numărul de aplicații raster Se pare că GDI trunchează datele încorporate la dimensiuni mai mici atunci când scoate o bandă orizontală a unui raster, dar în situații mai complexe, întregul raster este inclus în EMF Odată cu creșterea internetului și a camerelor digitale, sunt necesare din ce în ce mai multe bitmap-uri cu adâncimi de culoare mai mari, iar multe drivere de imprimantă folosesc spooling EMF, programatorii de aplicații se confruntă din ce în ce mai mult cu probleme de performanță atunci când lucrează cu bitmaps în EMF Decriptarea și vizualizatorul EMF prezentate în Fig imprimă dimensiunea fiecărei înregistrări și dimensiunea fiecărui raster, facilitând diagnosticarea problemelor de acest fel Un alt lucru este interesant: cum, cu structura EMF actuală, să rezolvăm această problemă cu modificări minime în GDI și este posibil ca aplicația să limiteze cumva dimensiunea EMF? Știm că umplutura (cum ar fi rasterele într-o înregistrare EMRBITBLT) este întotdeauna stocată după câmpurile deschise, dar sunt folosite offset-uri de de biți pentru a se referi la acestea Dacă decalajele ar putea fi negative sau în afara limitelor înregistrării EMF curente, diferite înregistrări EMF ar putea partaja aceeași copie a rasterului De asemenea, este posibil să se includă o înregistrare specială pentru crearea unui obiect bitmap în EMF, astfel încât bitmap-ul să fie stocat o singură dată în EMF și să poată fi referit ulterior prin index, ca un stilou sau o pensulă Regiunile din EMF Reprezentarea regiunilor în EMF are multe în comun cu reprezentarea rasterelor Regiunile nu au manipulatori asociați; crearea de regiuni și operațiunile cu acestea sunt pur și simplu efectuate fără a crea intrări în EMF Când o regiune este utilizată în contextul dispozitivului de înregistrare, datele regiunii sunt incluse în întregime în înregistrarea EMF Să luăm în considerare un exemplu - înregistrarea EMREXTSELECTCLIPRGN corespunzătoare funcțiilor Selectei!pRgn și ExtSelectCl!pRgn typedef struct tagEMREXTSELECTCLIPRGN EMR emr; DWORD cbRgnData: // Dimensiunea datelor din regiune în octeți DWORD și modul: BYTE RgnDataLI]: } EMREXTSELECTCLIPRGN: După cum puteți vedea din definiția EMREXTSELECTCLIPRGN, datele de regiune sunt incluse în înregistrare chiar și fără câmpul de compensare standard Matricea de dimensiuni variabile RgnData conține de fapt structura RGNDATA returnată de funcția GetRegionData Capitolul Metafișiere Ca și în cazul rasterelor, atunci când reutilizați o singură regiune, EMF păstrează mai multe copii ale datelor sale Dacă aplicația dvs funcționează cu regiuni complexe, aveți grijă Traiectorii în EMF Operațiile cu traiectorii în EMF sunt suficient de apropiate de funcțiile similare ale GDI EMF oferă tipuri de înregistrări pentru funcțiile de desenare BeginPath, CloseFigure, EndPath și toolpath Astfel, putem vorbi despre implementarea implicită a traiectoriei ca obiect GDI Funcțiile SaveDC și RestoreDC sunt, de asemenea, acceptate în EMF, ceea ce vă permite să utilizați de mai multe ori aceleași date de traseu Suportul pentru funcția SelectCl i pPath în înregistrările EMF reduce, de asemenea, nevoia de a încorpora datele de cale De exemplu, dacă o aplicație dorește să folosească o regiune de tăiere eliptică, poate folosi funcțiile BeginPath, Ellipse, EndPath și SelectClipPath în loc de funcțiile CreateEl ipticRgn și SelectRegion și poate evita includerea datelor regiunii în EMF Dacă utilizați funcția GetPath pentru a obține date de cale, apelați PolyDraw pentru a le desena; datele traseului sculei sunt încorporate într-o intrare EMRPOLYDRAW Palete în EMF EMF oferă tipuri de înregistrări pentru operațiunile de bază ale paletei GDI (funcțiile CreatePalette, SelectPalette, ResizePalette și RealizePalette) Paleta logică este interpretată de EMF ca un obiect GDI Cu toate acestea, GDI interpretează apelurile către SelectPalette într-un EMF ușor diferit Permiteți-mi să vă reamintesc că atunci când apelați SelectPalette, sunt trecuți trei parametri: un mâner de context de dispozitiv, un mâner de paletă și un steag Steagul este un semn de utilizare forțată a paletei de fundal Dacă fereastra de randare este fereastra activă și parametrul bForceBackground al funcției SelectPalette este FALSE, paleta va fi implementată ulterior ca paletă principală Toate diferențele dintre paleta principală și cea de fundal sunt că numai paleta principală poate elimina culorile non-statice din paleta sistemului pentru a realiza culori mai uniforme pentru o fidelitate mai bună a culorii; paleta de fundal poate ocupa doar poziții libere ale paletei sau poate selecta culori potrivite dintre cele existente În intrarea EMF pentru funcția SelectPalette (de tip EMRSELECTPALETTE), parametrul bForceBackground nu este fix Când redați un EMF, paleta logică este întotdeauna selectată ca paletă de fundal Motivul din spatele acestei decizii este că redarea EMF nu ar trebui să modifice culorile actuale ale ecranului, ceea ce ar duce la pâlpâirea enervantă și distorsiunea culorilor Paleta principală nu poate fi gestionată la nivel EMF, aparține unui nivel superior de procesare a mesajelor (adică se realizează în handlerele WM PAINT și WM PALETTECHANGED) Dacă aplicația dorește cu adevărat să potrivească paleta sistemului curent cu culorile EMF (adică, implementați paleta EMF ca paletă principală), Structura metafișierelor extinse are un tabel complet de culori, pe care GDI îl salvează în ultima intrare EMREOF În timpul procesului de înregistrare EMF, GDI acumulează intrările din paletă și le scrie în „paleta metafile” inclusă în intrarea EMREOF O aplicație poate obține paleta metafișier folosind funcția GetEnhMetaFilePaletteEntries UINT GetEnhMetaFI ePaletteEntries(HENHMETAFILE hemf, UINT cEntries, LPPALETTEENTRY Ippe): Acum gândiți-vă cum este implementată această funcție în GDI? Desigur, folosind mânerul EMF, GDI poate găsi intrarea EMREOF, dar cum să faceți acest lucru dacă nu există referințe directe? Repetarea tuturor intrărilor EMF ar dura prea mult dacă EMF ar trebui să fie încărcat în memorie de pe disc Indiciul se află în nSizeLast, ultimul câmp al înregistrării EMREOF Rețineți: câmpul nSizeLast este situat după tabelul de culori Din dimensiunea totală a EMF stocată în antetul EMF, GDI poate determina adresa câmpului nSizeLast Acest câmp stochează dimensiunea înregistrării EMREOF, care poate fi identificată cu ușurință drept începutul înregistrării EMREOF Operațiunile paletei sunt discutate în detaliu în Capitolul Următorul fragment arată cum să creați o paletă logică dintr-un tabel de culori EMF HPALETTE GetEMFPaletteCHENHMETAFILE hEmf, HDC hDC) { // Solicitați numărul de elemente int nu = GetEnhMetaFilePaletteEntries(hEmf, , NULL): dacă (nu palVersion = x : pLogPalette->palNumEntries = nu: // Obține date GetEnhMetaFilePaletteEntries(hEmf, nu, pLogPalette->palPalEntry): HPALETTE hPal = CreatePalette(pLogPalette): șterge[](BYTE *) pLogPalette: return hpal: } O aplicație poate implementa paleta logică returnată de funcția GetEMFPalette ca paletă principală și poate gestiona mesajele paletei Un ultim lucru de spus despre palete și EMF: înainte de a juca EMF cu funcția PlayEnhMetaFile, GDI resetează contextul dispozitivului la starea implicită și îl restabilește mai târziu Prin urmare, EMF nu va putea folosi conținutul paletei logice selectate în contextul dispozitivului înainte de redare Capitolul Metafișiere Sisteme de coordonate în EMF Redarea EMF implică două contexte de dispozitiv: referință și destinație Contextul dispozitivului de referință este utilizat la construirea EMF, iar în contextul de recepție, EMF este reprodus de funcția PlayEnhMetaFile Contextul dispozitivului de referință nu are manifestări externe, dar coordonatele stocate în înregistrările EMF sunt cele care se referă la el Fiecare context de dispozitiv are un sistem de coordonate logic și un sistem de coordonate dispozitiv, astfel încât cel puțin patru sisteme de coordonate sunt implicate în redarea EMF: О sistemul de coordonate logic al contextului de referință; O sistemul de coordonate al dispozitivului contextului de referință; O sistem de coordonate logic al contextului receptor; O este sistemul de coordonate dispozitiv al contextului de recepție Spun „cel puțin patru” pentru că nu există nicio garanție că se folosește un singur sistem de coordonate logic în contextul de referință EMF acceptă pe deplin setarea și modificarea sistemelor de coordonate logice cu funcțiile SetWindowExtEx, SetViewportExtEx, SetWorldTransform etc Apare o întrebare dificilă: să presupunem că comanda de a desena o linie lungă de inch în modul de afișare MM LOENGLISH sau MM HIENGLISH este scrisă în EMF Care este lungimea liniei atunci când redați EMF cu funcția PlayEnhMetaFile? O întrebare și mai dificilă: dacă selectăm o regiune de tăiere definită în sistemul de coordonate al dispozitivului, cum va fi interpretată la redarea EMF? Când redă un EMF, GDI poate interpreta intrările EMF care schimbă sistemele de coordonate ca o mapare de la sistemul de coordonate logic al contextului de referință la sistemul de coordonate al dispozitivului Fie ca această mapare să fie definită de matricea de transformare xformSrc Toate punctele din sistemul de coordonate logic al receptorului sunt, de asemenea, mapate la sistemul de coordonate al dispozitivului Fie ca matricea acestei transformări să se numească xformDst Astfel, maparea spațiilor de coordonate în redarea EMF este determinată de relația dintre sistemul de coordonate al dispozitivului din contextul de referință și sistemul de coordonate logic al contextului de recepție Să numim matricea de transformare corespunzătoare xformPlay Pe fig Figura prezintă două contexte de dispozitiv, patru spații de coordonate și trei transformări implicate în reproducerea EMF Matricea de transformare xformPlay este calculată din dreptunghiul cadru stocat în antetul EMF (rclFrame) și dreptunghiul trecut în apelul la PlayEnhMetaFile (IpRect) Rămâne doar convertirea rclFrame din unități de , mm în sistemul de coordonate al dispozitivului din contextul de referință Următorul fragment arată cum este calculată matricea de transformare Structura metafișierelor extinse Context de referință Sistem de coordonate logic Sistemul de coordonate al dispozitivului de context de referință G Sistemul de coordonate ■> dispozitiv de primire Cadrul logic al coordonatelor contextului receptor xforrnPtay rcIFrame în antetul EMF ipRect a trecut la apelarea PlayEnhMetaFile Orez Sisteme de coordonate și transformări implicate în redarea EMF // Transformă din coordonatele dispozitivului de context de referință // la coordonatele logice ale contextului receptor BOOL GetPlayTransformation(HENHMETAFILE hEmf, const RECT * rcPic, XFORM & xformPlay) { ENHMETAHEADER emfh; if ( GetEnhMetaF eHeader(hEmf, sizeof(emfh), & emfh) mm -> procente -> pixeli dispozitiv dublu sxO = emfh rcIFrame left / , / emfh szlM imeters cx * emfh szlDevice cx; syO dublu = emfh rcIFrame top/ / emfh szlM imeters cy * emfh szlDev ce cy; dublu sxl = emfh rcIFrame right/ / emfh szlM meters cx * emfh szlDevice cx; dublu syl = emfh rcIFrame bottom/ / emfh szlM meters cy * emfh szlDevice cy; // Raportul dimensiunii sursă-destinație double rx = (rcPIc->r ght - rcP c->left) / ( sxl - sxO ); dublu ry = (rcP c->jos - rcP c->sus) / (syl - syO); // x* = x * eMll + y * eM + eDx // y' = x * eM + y * eM + eDy xformPlay eMll = (float) rx; xformPlay eM = (float) ; xformPlay eDx = (float) (-sxO * rx + rcP c->stânga): xformPlay eM = (float) ; xformPlay eM = (float) ry; xformPlay eDy = (float) (- syO * ry + rcPic->top): Capitolul Metafișiere } captură( ) { returnează FALSE; } returnează TRUE: } Vă rugăm să rețineți că atunci când jucați, în loc de patru sisteme de coordonate, lucrăm cu trei matrice de transformare Matricea xformDst este determinată de aplicație în contextul dispozitivului receptor înainte de a reda EMF Matricea xformSrc definește inițial transformarea identității și se modifică dinamic pe măsură ce înregistrările EMF asociate cu schimbarea sistemului de coordonate sunt redate Legătura dintre aceste matrice este matricea de transformare xformPlay, care este definită în antetul EMF transmis funcției PlayEnhMetaFile De obicei, nu trebuie să vă gândiți la matricea de transformare a contextului de recepție, deoarece GDI funcționează de obicei cu coordonate logice atunci când este redat pe suprafața de recepție Toate coordonatele logice din EMF trebuie să treacă prin matricele de transformare xformSrc și xformPl ay înainte de a fi afișate pe suprafața de recepție Unele coordonate EMF (de exemplu, coordonatele din regiunile de tăiere) se referă la sistemul de coordonate al dispozitivului din contextul de referință Astfel de coordonate trebuie convertite în sistemul de coordonate al dispozitivului din contextul receptor GDI poate efectua această transformare prin aplicarea succesivă a matricelor xformPlay și xformDst După cum sa menționat mai sus, toate datele de regiune dintr-un EMF sunt stocate într-o structură RGNDATA, care este convertită într-un obiect de regiune GDI de către funcția ExtCreateRegion Funcția ExtCreateRegion este convenabilă prin faptul că, atunci când o apelați, puteți transmite o matrice de transformare care se aplică tuturor coordonatelor și puteți utiliza funcția CombineTransform pentru a combina două matrice de transformare Datorită operațiunilor de scalare și afișare utilizate atunci când lucrați cu EMF, rezoluția sistemului de coordonate logice al dispozitivului de referință are un impact semnificativ asupra calității graficii Dacă metafișierul a fost construit în modul de afișare MM TEXT pe un ecran cu o rezoluție de dpi, toate coordonatele vor fi reprezentate ca numere întregi în acest sistem de coordonate și în această rezoluție Când EMF este redat la mărire și pe dispozitive de înaltă rezoluție, coordonatele sunt scalate, ceea ce poate rupe alinierea textului sau poate crea margini zimțate în poligoane și trasee Comenzi de ieșire în EMF EMF acceptă o mare varietate de comenzi grafice GDI Din cele de tipuri de înregistrări EMF cunoscute, corespund funcțiilor grafice GDI Există mai multe alte tipuri de înregistrări disponibile pentru scrierea comenzilor OpenGL și pot exista și comenzi grafice nedocumentate Structura metafișierelor extinse De obicei, toate coordonatele dintr-un EMF sunt stocate ca valori pe de biți Cu toate acestea, opt tipuri de înregistrări EMF stochează datele de bază în format de biți, de exemplu, funcția PolyPolygon este reprezentată de două tipuri de înregistrări EMF - versiunea pe de biți a EMRPOLYPOLYGON și versiunea pe biți a EMR-P LYP LYG N Cele două versiuni diferă doar în formatul matricei de puncte Deși versiunile pe biți aproape înjumătățiesc costul memoriei dacă valorile coordonatelor logice sunt limitate la biți, nu se știe exact ce sisteme le folosesc Chiar și Windows generează înregistrări EMRPOLYPOLYGON în loc de EMRPOLYPOLYGON atunci când se realizează spool în format EMF Pentru funcțiile grafice elementare (cum ar fi LineTo și Rectangle), doar coordonatele originale sunt stocate în înregistrările EMF Pentru funcții mai complexe, GDI stochează caseta de delimitare în sistemul de coordonate al dispozitivului în înregistrările EMF În special, câmpul căsuței de delimitare este inclus în intrările EMRPOLYLINE, EMRPOLYGON și EMRSTRETCHBLT Caseta de delimitare este uneori foarte utilă - de exemplu, poate fi folosită pentru a exclude din redare înregistrările EMF care sunt tăiate sau depășesc limitele zonei de ieșire curente În special, această caracteristică poate fi utilizată de GDI atunci când pune în scenă un fișier EMF spooler, atunci când driverul de imprimantă primește doar o bandă orizontală per transfer, iar GDI îmbunătățește eficiența transferului prin transmiterea numai a acelor comenzi care ating dreptunghiul benzii curente Funcțiile de bază de ieșire cu un singur pixel, SetPixel și SetPixelV, sunt reprezentate de un singur tip de înregistrare EMF, EMRSETPIXELV Desigur, acest lucru se datorează faptului că dependența de valoarea de returnare a funcției trebuie eliminată în etapa de construire a EMF Funcțiile GDI pentru desenarea liniilor și curbelor sunt aproape complet acceptate în formatul EMF, cu excepția faptului că funcția MoeToEx nu returnează poziția anterioară a cursorului și funcția LineDDA nu este acceptată Cu toate acestea, LineDDA nu oferă o ieșire independentă, deoarece împarte doar o linie într-o secvență de coordonate pixeli într-un sistem de coordonate logic Toate ieșirile sunt realizate prin funcții de apel indirect furnizate de apelant; aceste comenzi vor fi salvate într-un fișier Funcțiile GDI pentru umplerea formelor închise sunt, de asemenea, complet acceptate De exemplu, funcțiile Chord, El lipse, Polygon și chiar PolyPolygon sunt reprezentate în EMF prin tipurile de înregistrare respective Pare puțin ciudat că pentru funcțiile care definesc o figură geometrică printr-o casetă de delimitare (de exemplu, Rectangle și El lipse), GDI exclude partea din dreapta jos când scrieți EMF De exemplu, dreptunghiul { , , , } este stocat ca { , , , } Astfel, dreptunghiurile stocate în EMF sunt interpretate ca includ toate laturile O interpretare similară este utilizată de GDI atunci când iese în modul grafic avansat La ieșire normală la scară : , GDI reproduce cu acuratețe forma originală a unor astfel de înregistrări EMF, dar poate apărea distorsiune atunci când este mărită De exemplu, două dreptunghiuri Rectangle( , , , ) și Rectangle( , , , ) trebuie să atingă întotdeauna, chiar și atunci când am mărit Dar, deoarece sunt reprezentate ca { , , , } și { , , , } în EMF, există un mic decalaj între ele pe măsură ce măriți Capitolul Metafișiere Trei funcții pentru umplerea formelor închise - Fi Rect, FrameRect și InvertRect - nu aparțin funcțiilor GDI Acestea sunt implementate de modulul de ferestre USER DLL, care redă folosind funcțiile GDL Aceste apeluri GDI - crearea și selecția pensulei, blitting simplu - vor fi stocate în EMF Funcțiile de desen pentru regiune FillRgn, FrameRgn, InvertRgn și PaintRgn sunt complet acceptate Obiectul de regiune GDI este convertit într-o structură de date de regiune și atașat la aceste comenzi grafice ca anexă Funcțiile pentru construirea traiectoriilor, spre deosebire de funcțiile pentru construirea regiunilor, sunt complet acceptate Funcțiile de trasare a traseului Fi , StrokeAndFi Path și StrokePath sunt de asemenea acceptate Deoarece aceste funcții se referă la obiectul traiectorie implicit în contextul dispozitivului, înregistrările lor EMF păstrează cea mai simplă casetă de delimitare Pentru a calcula caseta de delimitare GDI reală, GetPath ar trebui să fie apelat în timpul procesului de construire EMF EMF acceptă toate funcțiile de ieșire raster, de la cel mai simplu BitBlt la AlphaBlend, cu excepția PatBlt Funcția PatBlt este combinată cu forma mai generală BitBlt și folosesc aceeași notație EMRBITBLT Din cauza acestei concatenări, PatBlt este reprezentat de de octeți Dacă ar exista o intrare EMRPATBLT separată, aceasta ar avea o lungime de de octeți Text în EMF Celelalte patru tipuri de înregistrări EMF sunt pentru text Acestea reprezintă funcțiile GDI ExtTextOut și funcția PolyTextOut mai puțin cunoscută în versiunile ANSI și Unicode Funcția PolyTextOut este o secvență simplă de apeluri ExtTextOut combinate într-un singur apel Apelurile către TextOut sunt convertite de GDI în ExtTextOut În EMF, acestea sunt reprezentate de un singur tip, EMREXTTEXTOUT După cum s-a menționat mai sus, în GDI nu este necesar să treceți o matrice de distanțe între caractere atunci când apelați ExtTextOut, dar în EMF această matrice este întotdeauna completată cu datele corecte, ceea ce asigură o locație fixă, fără ambiguitate, a tuturor caracterelor dintr-un șir Din fig Figurile și arată că, pe măsură ce EMF crește, distanțele dintre simboluri cresc și ele Cu toate acestea, glifele caracterelor din aceste două figuri rămân de aceeași dimensiune, deoarece rezultatul folosește fontul implicit în contextul dispozitivului Dacă rezultatul a folosit fontul logic definit în program, glifele s-ar scala normal Știm că mărirea duce uneori la distorsiuni, deoarece datele originale sunt obținute prin rotunjirea unor valori reale mai precise Pentru a genera matrice precise de distanțe între caractere, o aplicație poate crea un context de dispozitiv logic de înaltă rezoluție și poate utiliza tehnicile descrise în capitolul anterior Experimentările au arătat că pe Windows cu componenta Uniscribe și suport multilingv instalat, apelurile pentru a crea, selecta și șterge fonturi logice sunt adăugate după intrările EMRTEXTOUT pentru funcțiile TextOut și ExtTextOut Ca rezultat, pot apărea o duzină de intrări inutile de fiecare dată când textul este trimis către EMF Windows NT și chiar versiunile timpurii ale Windows nu au nimic similar Structura metafișierelor extinse Apelurile către DrawText, DrawTextEx și TabbedTextOut din EMF se traduc într-o serie de apeluri către ExtTextOut intercalate cu apeluri către SetTextAlign, SetBkMode, MoveToEx și chiar SelectCli pRgn Ați putea fi surprins de numărul de intrări EMF care reprezintă doar un apel la DrawText sau TabbedTextOutput Independența hardware a EMF După o privire mai atentă asupra arhitecturii EMF, să revenim la întrebarea principală - în ce măsură este formatul EMF independent de dispozitiv? Independența hardware este un aspect critic al arhitecturii Enhanced Metafile Când descrie independența hardware a EMF, Microsoft susține că o imagine de x inci salvată în EMF își păstrează dimensiunile originale atunci când este imprimată pe o imprimantă de dpi și când este transmisă pe un monitor SuperVGA Apelul la CreateEnhMetaFile specifică dreptunghiul cadru care urmează să fie stocat în structura antetului EMF împreună cu rezoluția și dimensiunile suprafeței Aplicația poate solicita date din antet, poate obține dimensiunile imaginii în unități fizice, le poate converti în sistemul de coordonate logic al contextului actual al dispozitivului și poate specifica atunci când apelează PlayEnhMetaFile; în acest caz, metafișierul va avea exact aceleași dimensiuni cu care a fost scris EMF poate fi, de asemenea, scalat cu diferiți factori Pe scurt, în ceea ce privește independența dimensiunii hardware, EMF funcționează bine Pe de altă parte, un metafișier bazat pe un context de ecran depinde de dimensiunile ecranului, pentru care sistemul returnează întotdeauna x mm Rezoluția calculată din aceste dimensiuni este diferită de rezoluția logică a ecranului utilizată de majoritatea aplicațiilor O altă problemă pe care EMF încearcă să o rezolve este dependența hardware de culori Toate rasterele dependente de dispozitiv din EMF sunt convertite în rastere independente de dispozitiv Culorile sunt acumulate și stocate într-o paletă de metafișier pe care o aplicație o poate obține și implementa cu ușurință înainte de a juca EMF Prin urmare, dacă un metafișier folosește o paletă logică, culorile sale pot fi reproduse cu succes pe un alt dispozitiv care acceptă paleta Desigur, există câteva probleme minore la reproducerea culorilor pe dispozitivele High Color și True Color Dar dacă metafișierul a fost construit pe un dispozitiv True Color și nu folosește o paletă logică, redarea sa pe dispozitive cu paletă este slab acceptată la nivelul capabilităților EMF de bază Chiar dacă o aplicație selectează și implementează o paletă în tonuri de gri înainte de a reda un astfel de metafișier, GDI revine totuși la paleta de sistem de de culori standard Un alt aspect al independenței hardware este diferențele de implementare ale API-ului Win , în continuă schimbare Este posibil ca un metafișier creat pe Windows NT/ să nu fie întotdeauna redat complet pe Windows / , deoarece poate folosi funcții suplimentare care sunt acceptate numai pe Windows NT/ Pentru ca metafișierul dvs să fie utilizabil pe toate platformele Win active, trebuie să vă limitați la caracteristicile GDI implementate în Windows Capitolul Metafișiere Există și probleme cu fonturile Intrarea de creare a fontului logic EMREXTCREATEFONTINDIRECTW conține o descriere foarte detaliată a fontului sub forma unei structuri EXTLOGFONTW Include structura LOGFONT împreună cu numele complet calificat, stilul, versiunea, ID-ul dezvoltatorului și numărul PANOSE Ghidat de aceste date, GDI găsește o potrivire exactă sau cel puțin foarte apropiată Cu toate acestea, dacă nu poate fi găsit un font adecvat, EMF nu poate fi redat în mod normal pe alt computer Spooler-ul Windows NT/ rezolvă problema dependenței de fonturi prin încorporarea fonturilor în fișierul EMF al spoolerului înainte de a-l trimite la serverul de imprimare Cu toate acestea, formatul de bază EMF nu acceptă încorporarea fonturilor sau instalarea la cald a fonturilor pe sistem EMF nu are intrări pentru funcții precum AddFontResource Enumerarea înregistrărilor EMF Secțiunea anterioară a arătat cum să iterați peste toate înregistrările EMF API-ul Win acceptă interesanta funcție EnumEnhMetaFile, care permite unei aplicații să organizeze o enumerare a tuturor înregistrărilor atunci când redă un EMF într-un context de dispozitiv Aceasta este o caracteristică cu adevărat interesantă și unică, deoarece permite aplicației să monitorizeze redarea EMF și să intervină dacă este necesar typedef struct tagHANDLETABLE { HGDIOBJ objecthandleEU: // dimensiune variabilă } MANEBILĂ: typedef struct tagENHMETARECORD { DWORD IType: DWORD nSize: DWORD dParm[l]: // Variable Size } ENHMETAFILERECORD: typedef Int (CALLBACK* ENHMFENUMPROCKHDC hDC HANDLETABLE * IpHTable, CONST ENHMETARECORD * IpEMFR, int nObj, LPARAM IpData): BOOL EnumEnhMetaF e(HDC hDC, HENHMETAFILE emf, ENHMFENUMPPRC IpEnhMetaFunc LPVOID IpData CONST RECT * IpRect): BOOL PlayEnhMetaF eRecord(HDC hDC LPHANDLETABLE IpHandleTable, CONST ENHMETARECORD * IpEnhMetaRecord UINT nHandles): Funcția EnumEnhMetaFile primește cinci parametri: mânerul de context al dispozitivului de recepție, mânerul EMF, pointerii funcției de apel indirect și datele furnizate de aplicație și dreptunghiul de redare EMF pe suprafața de recepție În comparație cu PlayEnhMetaFile, au fost adăugați doi parametri noi - al treilea și al patrulea De fapt, funcțiile EnumEnhMetaFile și PlayEnhMetaFile sunt similare - ambele redă EMF în regiunea dreptunghiulară a contextului dispozitivului receptor Cu toate acestea, PlayEnhMetaFile apelează și funcția specificată pentru fiecare intrare EMF Funcția de apel indirect din EnumEnhMetaFile primește, de asemenea, cinci parametri: un mâner către contextul dispozitivului receptor, un pointer către tabelul monetar Enumerarea înregistrărilor EMF Manipulatorii EMF, un pointer către intrarea EMF curentă, dimensiunea tabelului de manipulare EMF și un pointer către datele furnizate de aplicație Tabelul de manipulare EMF este conceput pentru a converti indecșii de obiecte utilizați în EMF în manipulatoare de obiecte GDI Mărimea acestui tabel este stocată în înregistrarea antet EMF Informațiile despre fiecare intrare EMF sunt transmise funcției de apel indirect într-o structură ENHMETARECORD Intrarea EMF din această structură este un identificator de tip de de biți și un câmp de dimensiune de de biți, urmat de un număr de cuvinte duble Înregistrările EMF individuale sunt redate de funcția PlayEnhMetaFileRecord Această funcție a fost inclusă în GDI, astfel încât funcția de apel indirect să o poată apela și reda intrarea EMF curentă în contextul dispozitivului receptor Clasa C++ pentru a enumera intrările EMF Orice funcție de apel indirect care primește date de la aplicație este un bun candidat pentru implementarea unui obiect, deoarece puteți trece pointerul this unei funcții statice, care va trece apelul unei funcții virtuale C++ Urmează o clasă C++ generică pentru listarea intrărilor EMF clasa KEnumEMF { // Funcție virtuală pentru procesarea înregistrărilor EMF // Pentru a finaliza enumerarea, funcția returnează virtual int ProcessRecord(HDC hDC HANDLETABLE * pHTable const ENHMETARECORD * pEMFR int nObj) întoarce ; // Funcție statică de apel indirect // transferă controlul către funcția virtuală ProcessRecord static int CALLBACK EMFProc(HDC hDC HANDLETABLE * pHTable const ENHMETARECORD * pEMFR int nObj LPARAM IpData) { KEnumEMF * pObj = (KEnumEMF *) IpData: lf (IsBadWritePtr(pObj sizeof(KEnumEMF))) { afirmă (fals); returnează : } return pObj->ProcessRecord(hDC, pTable pEMFR, nObj); } public: BOOL EnumEMFIHDC hDC HENHMETAFILE hemf const RECT * IpRect) Capitolul Metafișiere return ::EnumEnhMetaFILE(hDC hemf, EMFProc, this, IpRect); } }: Clasa KEnumEMF conține o funcție virtuală ProcessRecord care preia rolul unei funcții de apel indirect Implementarea implicită returnează , terminând enumerarea intrărilor EMF Punctul de intrare principal al EnumEMF apelează funcția EnumEnhMetaFIle GDI și îi transmite o funcție statică, EMFProc, care transferă controlul către funcția virtuală C++ Această încapsulare a facilităților API Win în clasele C++ este bună, deoarece toate operațiunile API Win sunt efectuate într-un singur loc Puteți adăuga variabile noi în clasele derivate, puteți implementa noi caracteristici prin suprascrierea funcțiilor virtuale, ca să nu mai vorbim de crearea mai multor instanțe ale unei clase EMF cu mișcare lentă În cea mai simplă implementare a sa, funcția virtuală KEnumEMF::ProcessRecord este redusă la un simplu apel la PlayEnhMetaFileRecord De fapt, implementați manual PlayEnhMetaFile cu o ușoară întârziere din cauza codului suplimentar Deși acest cuvânt provoacă conotații negative, întârzierea potrivită ajută la urmărirea redării metafișierelor Clasa KDel ayEMF de mai jos se întrerupe pentru scurt timp înainte de redarea înregistrării clasa KDelayEMF : KEnumEMF public { int m delay; virtual int ProcessRecord (HDC hDC, HANDLETABLE * pHTable, const ENHMETARECORD * pEMFR, int nObj) { Sleep(m delay); returnează PlayEnhMetaFileRecord(hDC, pHTable, pEMFR, nObj): } public: KDelayEMF(întârziere int) { m delay = întârziere: } }: // Exemplu de utilizare KDelayEMF întârziere(lo): delay EnumEMF(hDC, hEmf, IpPictureRect); Dacă v-ați întrebat vreodată cât de bune sunt create efectele de text D, copiați textul D în programul EMF din acest capitol și urmăriți-l cu încetinitorul Construcția unei linii tridimensionale este prezentată în fig Enumerarea înregistrărilor EMF Orez EMF cu mișcare lentă Urmă de redare EMF De la cea mai simplă întârziere, trecem la următorul nivel - urmărirea redării EMF și afișarea informațiilor într-o fereastră de text Clasa KTraceEMF folosește clasa KEmfDC pentru a decoda înregistrările EMF și pentru a afișa date într-o fereastră de text implementată de clasa KLogWindow clasa KTraceEMF : KEnumEMF public { int m nSeq; KEmfDC m emfdc: int m value[ ]: HGDIOBJ m object[ ]: FLOAT m float[ ]; virtual int ProcessRecord(HDC hDC HANDLETABLE * pHTable const ENHMETARECORD * pEMFR Int nObj) { CompareDC(hDC); m pLog->Log("Md: £ x £ d % d " m nSeq++ pEMFR pEMFR-> Type, pEMFR->nS ze); m pLog->Log(m emfdc DecodeRecord((const EMR *) pEMFR)): m pLog->Log("\r\n"): returnează PlayEnhMetaFileRecord(hDC phTable pEMFR nObj); } public: KLogWindow*m pLog: void CompareDC(HDC hDC): Capitolul Metafișiere KTraceEMFCHINSTANCE hlnst) m pLog = KLogWindow nou: // Memoria alocată este eliberată // la procesarea WM NCDESTROY m pLog->Create(hInst, "EMF Trace"): m nSeq = : memset(m value, OxCD, sizeof(m value)): memset(m object, OxCD, sizeof(m object)): memset(m float, OxCD, sizeof(m float)): } }: Una dintre caracteristicile suplimentare implementate în clasa KTraceEMF este compararea atributelor contextului dispozitivului înainte de reluare, între înregistrările EMF și după reluare Atributele contextului dispozitivului sunt interogate de funcțiile GDI normale (cum ar fi GetBkMode), stocate în trei matrice și comparate cu valorile anterioare Prin observarea modificărilor în atributele contextului dispozitivului, puteți înțelege mai bine cum este implementată redarea EMF Următoarele sunt date de urmărire parțială obținute folosind clasa KTraceEMF /////////////// Înainte de ieșire ///////////////// Modul grafic WT eMll , WT eM , WT eM , WT eM , WT eDx , WT eDy , Pen x b Perie x Font x a Paleta xa ca /////////////// Pornire ieșire ///////////////// GraphicsMode WT eDx WT eDy Font Palette , , x a x b : e // Titlu : e MoveToExthDC , , NULL); : e LineTofhDC , ): : e a MoveToExthDC , NULL); : e b LineToChDC , ); : e c Dreptunghi(hDC ); : e dc Dreptunghi(hDC ): : e f EllIpseChDC ); : e c EllipselhDC, , , , ); : e PatBlt(hDC, , BLACKNESS) : e PatBlt(hDC , PATINVERT) Enumerarea înregistrărilor EMF : e ec hObj[l]=CreateSol dBrush(RGB( x x x )): : e SelectObject(hDC, hObjLl]): Perie: x fl e : e // EMREOF( ) /////////////// După ieşire ///////////////// Mod grafic: WT eDx: , WT edy: , Font: x a Paleta : xa ca Se întâmplă ceva foarte interesant Înainte de a apela EnumEnhMetaFile, contextul dispozitivului este în modul grafic compatibil cu atribute implicite (cu excepția tonurilor de gri) Când funcția de apel indirect începe să proceseze înregistrarea antetului EMF, contextul este comutat în modul grafic avansat, matricea de transformare a lumii este actualizată, iar mânerele fontului/paleta sunt înlocuite cu obiecte GDI standard Acest lucru indică faptul că pe Windows NT/ , GDI utilizează modul grafic avansat cu transformarea lumii atunci când redă EMF, iar alte atribute de context ale dispozitivului sunt întotdeauna resetate la starea lor implicită înainte de a reda intrările EMF Modul grafic avansat este foarte convenabil pentru redarea EMF GDI pur și simplu concatenează cele trei matrice de transformare (vezi Figura ), atribuie rezultatul ca matrice de transformare mondială atunci când redă EMF și apoi emite toate intrările cu coordonatele originale stocate în EMF Rămâne doar convertirea regiunii de tăiere din sistemul de coordonate al dispozitivului din contextul de referință în sistemul de coordonate al dispozitivului din contextul de recepție În Windows / , modul grafic avansat nu este implementat de fapt, așa că GDI trebuie să folosească modul de afișare MM ANISOTROPIC în combinație cu o setare specială de afișare fereastră/vizualizare echivalentă cu matricea de transformare combinată Urmărirea afișează, de asemenea, informații despre modificările aduse obiectelor GDI asociate cu contextul dispozitivului Vedem că GDI înlocuiește întotdeauna aceste obiecte cu obiecte GDI standard înainte de a reda EMF În special, acest lucru explică de ce selectarea unei palete logice înainte de redare nu are ca rezultat culoarea corectă la EMF-uri care nu conțin propria paletă logică Clasa KTraceEMF poate fi, de asemenea, înzestrată cu alte abilități utile - de exemplu, clasa poate urmări crearea, selecția și ștergerea obiectelor GDI și poate căuta posibile scurgeri de resurse în EMF Deși GDI eliberează întotdeauna mânerele rămase în tabelul mâner EMF, remedierea scurgerii de resurse va ajuta la depanarea codului de compilare EMF Schimbarea EMF dinamică Intrarea EMF transmisă funcției de apel indirect este doar în citire; nu poate fi modificat și returnat la GDI Cu toate acestea, aplicația Capitolul Metafișiere poate face o copie a acestei intrări, o poate modifica în timpul execuției și o poate transmite către GDI pentru ieșire Cu alte cuvinte, programul poate schimba dinamic EMF și poate transmite versiunea modificată către GDI Mai jos este o clasă simplă care convertește toate culorile textului, fundalului, stiloului și pensulei în tonuri de gri Dacă EMF nu conține hărți de biți de culoare, redarea de către clasa KGrayEMF convertește metafișierul de culoare în gri Codul pentru conversia imaginilor color în tonuri de gri este prezentat în Capitolul ini ine void MaptoGray(COLORREF & cr) { if ( (cr & OxFFOOOOOO) != PALETTEINDEX(O) ) // Nu este un index {// palete BYTE gri = ( GetRValue(cr) * + GetGValue(cr) * + GetBValue(cr) * + ) / : cr = (cr & OxFFOOOOOO) | RGB (gri gri gri): } } clasa KGrayEMF : KEnumEMF public { virtual int ProcessRecord(HDC hDC HANDLETABLE * pHTable const ENHMETARECORD * pEMFR int nObj) { int rslt: comutator ( pEMFR->iType ) { cazul EMR CREATEBRUSHINDIRECT: EMRCREATEBRUSHINDIRECT cbi: Cbi = * (const EMRCREATEBRUSHINDIRECT *) pEMFR: MaptoGray(cbi Ib lbColor): rslt - PlayEnhMetaFileRecordthDC pHTabel, (const ENHMETARECORD *) & cbi nObj): } pauză: cazul EMR CREATEPEN: { EMRCREATEPEN cp: cp = * (const EMRCREATEPEN *) pEMFR: MaptoGray(cp opn opnColor): rslt = PlayEnhMetaFileRecord(hDC pTable (const ENHMETARECORD *) & cp nObj): } pauză: caz EMR SETTEXTCOLOR: caz EMR SETBKCOLOR: EMRSETTEXTCOLOR Stc: stc = * (const EMRSETTEXTCOLOR *) pEMFR: Enumerarea înregistrărilor EMF MaptoGray(stc crColor); rslt = PlayEnhMetaFileRecord(hDC, pHTable, (const ENHMETARECORD *) & stc, nObj); } pauză; Mod implicit: rslt = PlayEnhMetaF eRecord(hDC, pHTable, pEMFR, nObj); return rslt; } }: Clasa KGrayEMF este un membru distinct al unei întregi categorii de clase de transformare aplicate EMF în timpul redării În mod similar, puteți modifica grosimea stiloului pentru a se potrivi cu setările dispozitivului dvs grafic, puteți înlocui modelele de linii care sunt prea mici pentru a fi imprimate pe o imprimantă, puteți elimina toate hărțile de biți din document sau puteți ajusta culorile Construirea de metafișiere derivate Contextul dispozitivului de recepție al funcției PlayEnhMetaFile (și, prin urmare, metoda KEnumEMF::EnumEMF) poate fi orice context valid, inclusiv unul metafișier Dacă apelați PlayEnhMetaFile pe un context de dispozitiv EMF și treceți o funcție de apel indirect scrisă special, controlați de fapt procesul de creare a unui nou metafișier extins pe baza intrărilor de metafișier existente Este întotdeauna foarte interesant să folosești astfel de oportunități, deși, alături de noile cunoștințe, te așteaptă multe surprize Următoarele sunt funcția FilterEMF și funcția de ajutor MaplOumToLogical pe care o folosește void MaplOumToLogical (HDC hDC, RECT și rect) { POINT * pPoint = (PUNCT *) & rect; // Treceți de la unitățile de , mm la pixelii actuali ai dispozitivului pentru (int i= ; i E” „ @PJL ENTER LANGUAGE=PCL GUI ” „ E” CmdStartDoc PCLJJSJ-ETTER: PCL MEDSOURCE TRAY PREÎNCĂRCARE PCL MEDSOURCE „ &u D *o W ” „ & A” „ & H” „ & - H” Cunoașterea spoolerului PCL MEDIA PLAIN PCL PQ NORMAL PCL CRD K C PORTRET PCL ORIENT „ *g W " CmdStartPage „ & E *p y X & L *rlA” Date raster „ ” „ ” „ ” CmdEndPage „ *rC ” PJL EXIT LANGUAGE „ H- X” „ *oOM” Comenzile PCL încep cu un caracter de serviciu din setul ASCII ( x B în sintaxa C) O pagină tipărită în PCL începe cu o duzină de comenzi de inițializare care transmit imprimantei informații despre tipul de limbă, dimensiunea și sursa hârtiei, tipul suportului, calitatea imprimării, orientarea și așa mai departe Urmează blocul principal de date codificate bitmap, urmat de comenzile finale Limbajul descrierii paginii A treia categorie de limbi acceptă date text și grafice vectoriale împreună cu date raster Aceste limbaje de control al imprimantei permit descrierea unei pagini folosind o varietate de forme geometrice, text, culori și operațiuni de ieșire care amintesc de comenzile GDI Acestea sunt denumite în mod obișnuit Limbaje de descriere a paginii (PDL) Această categorie include PostScript, PCL și PCL cu suport pentru grafică vectorială Imprimantele care acceptă limbaje moderne de descriere a paginilor trebuie să fie semnificativ mai puternice decât imprimantele cu limbaje bitmap Utilizarea primitivelor geometrice pentru a descrie pagini înseamnă că ordinea comenzilor grafice în fluxul de date nu poate fi prezisă în avans Memoria imprimantei trebuie să fie suficientă pentru a stoca o pagină întreagă de primitive grafice, sortate în ordinea în care apar pe pagină, să le reproducă în format raster, să efectueze procesarea semitonurilor și să le trimită la tipărire De fapt, imprimantei îi sunt delegate funcțiile efectuate în mod normal de un driver de imprimantă raster Firmware-ul imprimantei trebuie, de asemenea, să poată scoate tot textul, pentru care fie utilizează cartuşul de fonturi al imprimantei, fie descarcă fonturi TrueType de pe computerul gazdă Suportul pentru un limbaj puternic de descriere a paginii simplifică driverul de imprimantă în anumite moduri, deoarece elimină necesitatea redării pe computerul gazdă Se poate presupune că imprimarea ar trebui să fie mai rapidă și să consume mai puține resurse pe computerul gazdă Totuși, maparea comenzilor GDI la comenzile de marcare a țării Capitolul prostratul devine uneori o sarcină foarte dificilă Situația este complicată de suportul fonturilor dispozitivului, înlocuirea fontului și încărcarea Următorul este un exemplu de fișier PostScript generat de driverul de imprimantă HP Color Laserjet PostScript £- X@PJL JOB @PJL ENTER LANGUAGE = POSTSCRIPT £!PS-Adobe- &&T tle: Document ^Creator: Pscript dll Versiunea HOrientare: Portret HPage Order: Special HTargetDevice: (HP Color LaserJet ) ( ) Nivelul Wanguage: HEndComments HIncludeResource: fontTimesNewRomanPSMT F /F / T /TimesNewRomanPSMT mF /F S F [ - ] mFS F S setfont muta la (Limbajul de control al imprimantei)[ ]xshow arata pagina (HEPgina: ]ȘI) = HPageTrailer Shgaieg HBoundingBox: Npagini: (HELlastPageJH) = HEOF J- X@PJL EOJ - GBP După un titlu lung, macrocomenzi și definiții, începe conversia secvențială a comenzilor grafice GDI în comenzi PostScript Instrucțiunea setfont selectează fontul Times New Roman ca font curent, instrucțiunea moveto setează poziția de ieșire, instrucțiunea xshow este pentru afișarea textului la poziția exactă a caracterelor, iar instrucțiunea showpage începe tipărirea paginii Ieșire directă prin port După cum sa menționat mai sus, datele de nivel scăzut generate de driverul de imprimantă sunt transmise de monitorul portului către driverul portului I/O și în cele din urmă trimise către imprimantă Monitorul de porturi, cu operațiuni standard de fișiere Win , deschide mânerul pentru driverul I/O și redirecționează Cunoașterea spoolerului îi oferă date Dacă aplicația cunoaște limbajul de control al imprimantei, poate face același lucru și poate comunica direct cu imprimanta Următorul fragment arată cum să transferați un fișier pe un port de imprimantă BOOL SendFile(HANDLE hOutput const TCHAR * nume de fișier bool bPrinter) { HANDLE hFile = CreateF e(nume fișier GENERIC READ FILE SHARE READ NUL OPEN EXISTING, FILE ATTRIBUTE NORMAL NUL); lf ( hFile==INVALID HANDLE VALUE ) returnează FALSE; charbuffer[ ]; pentru (Int size = GetFileS ze(hF le, NULL); dimensiune: ) { DWORD dwRead = dwWritten = ; lf ( ! ReadFI e(hF e tampon min(dimensiune slzeof(tampon)) &dwCitiți NUL) ) pauză; dacă (bPrinter) WritePrinter(hOutput buffer dwRead & dwWritten); altfel WriteFile(hOutput buffer dwRead & dwWritten NULL); dimensiune -= dwRead; } returnează TRUE; } void Demo WritePort(void) { KFileDialog fd; if ( fd GetOpenFileName(NULL „prn” „Date brute de imprimantă”)) { HANDLE hPort = CreateFileC'lptl;" GENERIC WRITE FILE SHARE READ NUL OPEN-EXISTING, FILE ATTRIBUTE NORMAL NUL); if ( hPort!=INVALID HANDLE VALUE ) { SendF e(hPort fd m TitleName, false); CIoseHandle(hPort); } } } Funcția SendFile deschide un manipulator pentru fișierul de intrare și copiază blocurile de date în fișierul de ieșire Funcția Demo WritePort afișează o casetă de dialog în care utilizatorul selectează un fișier de trimis la imprimantă, creează un handle de port I/O și apelează SendFile Scrierea datelor de nivel scăzut în limbajul de control al imprimantei este adesea necesară atunci când se adaptează programele DOS, precum și în aplicațiile care limitează Capitolul text sau care cred că pot face treaba mai bine decât un driver obișnuit de imprimantă Aplicația poate salva, de asemenea, datele de nivel scăzut generate de driverul de imprimantă (print to file), le poate descărca și trimite direct la imprimantă fără a fi nevoie de GDI Pe Windows NT/ , portul LPT : nu corespunde unui port hardware normal, deși apelul la WriteFile trece prin aceeași funcție de sistem ca și scrierea pe un port real Utilități precum WINOBJ (www sysinternals com) arată că LPT : este o legătură simbolică către Device\ NamedPipe\Spooler\LPTl Se pare că ieșirea este încă efectuată sub controlul spoolerului Dispozitivul care arată ca un port real se numește NONSPOOLED LPT și este o legătură simbolică către \Device\ParallelO Dacă spooler-ul nu rulează (de exemplu, dacă a fost terminat cu comanda net stop spooler), încearcă să deschidă LPT : eșuează Imprimare Spool O altă modalitate de a ieși la o imprimantă este utilizarea unui spooler API API-ul Win include un set bogat de funcții spooler care pot fi utilizate de o aplicație pentru a obține informații despre starea spoolerului, pentru a gestiona lucrările de imprimare, a seta opțiunile imprimantei sau a trimite date direct către imprimantă Aceste funcții sunt rareori numite în aplicațiile Windows, deoarece multe dintre caracteristicile standard pot fi accesate prin casete de dialog standard sau prin aplicația Imprimante din panoul de control Din acest motiv, ne vom uita doar la unele dintre funcțiile spooler BOOL OpenPrinter(LPTSTR pPrintName, LPHANDLE phPrinter, LPPRINTER-DEFAULTS pDefault); DWORD StartDocPrinter(HANDLE hPrinter, DWORD Level, LPBYTE pDocInfo); BOOL StartPagePrinter(HANDLE hPrinter); BOOL WritePrinter(HANDLE hPrinter, LPVOID pBuf DWORD cbBuf, LPWORD pcWritten); BOOL EndPagePrinter(HANDLE hPrinter); BOOL EndDocPrinter(HANDLE hPrinter); BOOL ClosePrinter(HANDLE hPrinter); BOOL AbortPrinter(HANDLE hPrinter); Funcția OpenPrinter preia un nume de imprimantă și un pointer către o structură PRINTER DEFAULTS cu parametri impliciti și returnează un handle la obiectul imprimantă menținut de DLL-ul Win spooler Rețineți că acest manipulator nu aparține nici nucleului, nici obiectelor GDI, deci poate fi folosit doar de funcțiile spooler În implementarea actuală a Windows NT/ , mânerul imprimantei este pur și simplu un indicator către un spațiu de adrese în modul utilizator Funcția StartDocPrinter îi spune spoolerului că a sosit un document nou și trebuie să fie pus în coadă pentru imprimare Ultimul parametru al acestei funcții este un pointer către o structură DOC INFO sau D C INF care specifică numele documentului, numele fișierului de ieșire și tipul de date pentru lucrarea de imprimare DLL-ul spool creează o nouă lucrare de imprimare cu funcția AddJob și un fișier spool în directorul spooler Funcția StartDocPrinter este utilizată în tandem cu funcția Cunoașterea spoolerului EndDocPrinter, care încheie lucrarea de imprimare, o elimină din spooler și eliberează toate resursele alocate Funcția StartPagePrinter îi spune spoolerului să înceapă o pagină nouă După apelarea acestei funcții, aplicația poate trimite date către spooler cu funcția WritePrinter Fiecare apel la StartPagePrinter trebuie să fie asociat cu un apel asociat la EndPagePrinter, după care începe o nouă pagină sau se încheie lucrarea de imprimare Dacă apare o eroare, lucrarea de imprimare poate fi anulată cu funcția Abort-Printer Funcțiile spooler sunt exportate de clientul spooler Win DLL winspool drv, astfel încât programele Windows să poată interacționa cu spooler Cu toate acestea, implementarea reală a spooler-ului rezidă într-un proces de sistem separat (spoolsv exe) DLL-ul client comunică cu spooler-ul prin mecanismul RPC De exemplu, funcția StartPagePrinter apelează RpcStartPagePrinter, care la rândul său apelează NdrCl ientCa! Funcțiile spooler pot fi utilizate și pentru a trimite date de nivel scăzut către imprimantă Cu toate acestea, suportul complet pentru spooling vă permite să faceți mult mai mult Mai precis, puteți trimite orice date, atâta timp cât sunt suportate de motorul de imprimare care este responsabil de procesarea datelor Pentru a verifica formatele de date acceptate de motorul de imprimare pentru un anumit driver de imprimantă, deschideți fereastra cu proprietățile imprimantei și faceți clic pe fila Avansat Pe fig Figura - arată ce formate sunt acceptate pentru motorul de imprimare standard Windows Avansat Alw$ avafeble G AvAbte bish Setectinș un proces diferit de priitw poate avea ca rezultat opțiuni diferite să fie аѵаіІвэ hr diMt tipuri de date serviciul dumneavoastră nu specifică un tip de date , Orivec jHPDeskJet the sefoctton leu wlllbeused - • /-C Startptirstogal "JP, Start prWfegițn, RAW [FF auto] NT EMF NT EMF NT EMF NT EMF TEXT RAW [FF atașat] Orez Tipuri de date acceptate de procesorul standard de imprimare Windows Capitolul După cum puteți vedea din figură, procesorul de imprimare standard Windows acceptă trei categorii de tipuri de date: nivel scăzut, text și NT EMF Deși sunt enumerate patru versiuni de NT EMF, specificațiile exacte și diferențele dintre ele nu sunt documentate De asemenea, rețineți că numele WinPrint nu se potrivește cu DLL-ul fizic Procesorul de imprimare standard Windows face parte din procesorul de imprimare local (localspi dll), după cum evidențiază numele funcțiilor exportate, cum ar fi PrintDocumentOnPrintProcessor Un mic experiment îi va convinge pe toți scepticii că API-ul spooler documentat gestionează bine fișierele EMF Următoarea funcție ilustrează utilizarea funcțiilor spooler cu fișiere EMF void Demo WritePrinter(void) { PRINTDLGpd: memset(&pd, , sizeof(PRINTDLG)): pd ISructSize = dimensiunea(PRINTDLG): dacă ( PrintDlg(&pd)==IDOK ) { MÂNER hPrinter; DEVMODE * pDevMode = (DEVMODE *) GlobalLock(pd hDevMode); PRINTER DEFAULTSprn; prn pDatatype = "NT EMF "; prn pDevMode = pDevMode; prn DechiredAccess = PRINTER ACCESS USE; if ( OpenPrinter((char *) pDevMode->dmDeviceName & hImprimantă &prn)) { KFILeDIalog fd; Dacă ( fd GetOpenF eName(NULL "spl", "Windows EMF Spool file") ) DOC INFO docinfo: docinfo pDocName = "Se testează WritePrinter"; docinfo pOutputFile = NULL; docinfo pDatatype = "NT EMF "; \StartDocPrinter(hPrinter, , (BYTE *) & docinfo); StartPagePrinter(hPrinter); SendFile(hPrinter fd m T tleName, adevărat); EndPagePrinter(hPrinter); EndDocPrinter(hPrinter); Cunoașterea spoolerului CIosePrinter(hPrinter): } if ( pd hDevMode ) GlobalFree(pd hDevMode); dacă ( pd hDevNames ) GlobalFree(pd hDevNames): } } Funcția Demo WritePrinter creează o casetă de dialog standard pentru selectarea unei imprimante pe care să se imprime Dacă s-a făcut clic pe butonul OK în caseta de dialog, manipulatorul global al blocului structurii DEVMODE care conține toate opțiunile de imprimare este introdus în structura PRINTDLG Mânerul DEVMODE este convertit într-un pointer și utilizat pentru a popula câmpurile structurii PRINTER-DEFAULTS transmise funcției OpenPrinter Dacă apelul la OpenPrinter are succes, programul solicită utilizatorului să selecteze fișierul EMF spooler Windows NT/ Funcția apelează apoi StartDocPrinter, specifică tipul de date „NT EMF ” și trimite conținutul fișierului EMF cu funcția SendFile (vezi mai sus) Dacă totul a mers bine, fișierul EMF este transmis driverului de imprimantă specificat și tipărit Cheia succesului Demo WritePrinter este formatul corect al fișierului spooler EMF Capitolul despre EMF a menționat modalități de obținere a unui fișier spooler EMF — folosind utilitarul EMFScope în Windows / sau comanda de salvare a fișierului spooler în Windows NT/ Au fost prezentate, de asemenea, instrumente pentru decodarea fișierelor EMF în general și fișierele spooler EMF în special Această tehnică permite aplicațiilor să trimită date de tipărire la nivel scăzut sau spool în format EMF către imprimantă fără implicarea directă a GDI În combinație cu capacitatea de a primi fișiere EMF de la un spooler, devine posibilă reutilizarea unui fișier spooler fără a rula aplicația originală care a creat fișierul Acest lucru poate fi util atunci când construiți instrumente universale de procesare a documentelor care oferă un singur mecanism pentru procesarea datelor de ieșire ale diferitelor aplicații Rețineți că fișierul spooler EMF trebuie să fie compatibil cu imprimanta pe care imprimați, deoarece contextul driverului de imprimantă este luat ca referință atunci când fișierul spooler EMF este construit De asemenea, rețineți că funcția Demo WritePrinter utilizează o structură DEVMODE cu setările curente ale imprimantei Ar fi mai corect să extrageți structura DEVMODE din fișierul SHD generat împreună cu fișierul EMF Acest lucru se datorează faptului că unele câmpuri ale structurii DEVMODE s-au modificat de la ultima dată când a fost construit fișierul EMF Să ne uităm la o diagramă mică pentru a vă ajuta să înțelegeți mai bine cum este implementată spooling EMF Dacă, la crearea unui job nou, GDI decide că este permisă spooling EME, atunci un nou job spooler EMF este creat în același mod Pentru fiecare apel de funcție GDI, datele de scriere ale fișierului EMF sunt transmise spoolerului folosind WritePrinter Funcția StartDoc GDI apelează StartDocPrinter, funcția StartPage apelează StartPagePrinter și așa mai departe, iar scoaterea din coadă este gestionată de motorul de imprimare Desigur, aceasta este doar o diagramă conceptuală simplificată Vom reveni la dialogurile imprimantei și la structura DEVMODE atunci când descriem imprimarea GDI Capitolul Procesor de imprimare EMF Când trimiteți date spool în format EMF către funcția WritePrinter, apare o întrebare interesantă: ce face exact motorul de imprimare EMF? Secțiunea „Arhitectura sistemului de imprimare” din Capitolul al acestei cărți oferă o descriere destul de detaliată a funcționării motorului de imprimare în contextul arhitecturii sistemului de imprimare Windows Și acum vom arunca o privire amplă la ceea ce face procesorul de imprimare Windows Motorul de imprimare este o componentă personalizabilă a arhitecturii sistemului de imprimare Windows, care a fost concepută având în vedere viitorul Înainte de apariția Windows , procesorul de imprimare abia era folosit din cauza capacităților sale limitate Când procesorul de imprimare a primit o lucrare EMF de la spooler, pur și simplu a transmis-o driverului de imprimantă cu funcția GdiPlayEMF (gdoPlaySpoolStream pe Windows / ) Declarația funcției GdiPlayEMF în Windows NT arată astfel: BOOL GdiPIayEMF(LPWSTR pwszPrinterName, LPDEVMODEW pDevmode ELPWSTR pwszDocName EMFPLAYPROC prnEMFPlayFn, HANDLE hPageQuery); După cum puteți vedea, motorul de imprimare primește doar numele imprimantei, DEVMODE și numele documentului Tot ce poate face este să scoată mai multe instanțe ale documentului apelând GdiPlayEMF de mai multe ori Ultimele două opțiuni sunt pentru redarea selectivă a paginilor EMF individuale, dar această caracteristică nu este acceptată în Windows NT În Windows , capacitățile procesorului de imprimare au fost îmbunătățite Acum poate controla randarea paginilor EMF, poate combina mai multe pagini logice pe o singură pagină fizică, poate schimba ordinea în care sunt tipărite paginile dintr-un document și chiar poate aplica transformări paginilor logice Cu aceste îmbunătățiri, motorul de imprimare Windows vă permite să imprimați mai multe pagini pe o singură pagină fizică, să imprimați pagini în ordine inversă, să imprimați mai multe copii ale fiecărei pagini și să imprimați broșuri și contururi de pagină Toate aceste caracteristici sunt implementate central și ușor de extins fără a modifica GDI sau driverele de imprimantă Accesul la noile capabilități ale motorului de imprimare deschide noi funcții exportate de GDI Următoarele sunt declarațiile celor mai importante trei funcții HANDLE GdîGetPageHandleCHANDLE SpoolFileHandle Pagina DWORD LPDWORD pdwReserved): BOOL GdiPlayPageEMF(HANDLE SpoolFileHandle HANDLE hEmf RECT * prectDocument, RECT * prectBorder); HDC GdiGetDC(HANDLE SpoolFi eHandle): Funcția GdiGetPageHandle permite procesorului de imprimare să obțină mânerul unei anumite pagini din fișierul EMF al spoolerului Amintiți-vă că acest mâner nu este nici un mâner de obiect GDI sau nucleu și nici un pointer către datele grafice EMF Poate fi folosit doar de funcția GdiPlayEMF pentru a reda o pagină prin driverul de imprimantă Opțiunea prect-Document vă permite să scalați pagina EMF logică la o porțiune a paginii fizice pentru imprimarea mai multor pagini pe o singură coală sau pentru ieșirea unei broșuri Parametrul opțional prectBorder definește dreptunghiul exteriorului Cunoașterea spoolerului conturul paginii și simplifică aspectul vizual al mai multor pagini logice pe o singură pagină fizică Funcția Gdi GetDC returnează procesorului de imprimare un handle de context al dispozitivului GDI normal care poate fi folosit pentru a aplica o transformare mondială înainte de redarea EMF Ca rezultat al aplicării transformărilor lumii, motorul de imprimare poate roti sau întoarce paginile Un exemplu de cod sursă al motorului de imprimare EMF este inclus în Windows NT / DDK (directorul src\print\genprint) Funcțiile speciale GDI pentru lucrul cu procesorul de imprimare EMF sunt documentate în DDK Poate aveți o întrebare - cum funcționează funcția GdiPlayPageEMF? Dacă mai multe pagini logice pot fi tipărite pe o singură pagină fizică, atunci paginile EMF individuale nu pot fi redate într-un context de dispozitiv (în special pentru driverele de imprimantă care utilizează suport GDI pentru striping), deoarece acest lucru ar necesita un strat suplimentar de construcție și redare EMF Funcția GdiPlayPageEMF nu redă EMF în contextul dispozitivului imprimantei; în schimb, doar stochează noua pagină logică în structura internă de date a GDI Redarea mai multor pagini logice începe doar cu un apel la GdiPlayPageEMF Rularea Gdi EndPageEMF în depanator dezvăluie câteva dinamici interesante de imprimare în GDI Pentru a monitoriza Gdi EndPageEMF, atașați un depanator la procesul spooler în Task Manager făcând clic dreapta pe numele procesului spooler și selectând Debug din meniul contextual După atașarea spooler-ului la proces, setați un punct de întrerupere la GdiEndPageEMF@ în modulul gdi dll Acum puteți începe lucrarea de imprimare Se pare că Gdi EndPageEMF apelează funcția GDI StartPage și funcția internă StartBanding, apoi apelează funcțiile Internai-GdiPlayPageEMF și NextBand într-o buclă Funcția InternaiGdiPlayPageEMF setează transformarea lumii și apelează interesanta funcție PrintBand Funcția PrintBand apelează funcția de sistem NtGdiGetPerBandInfo, care corespunde punctului de intrare documentat al driverului de imprimantă și transmite informații despre banda următoare către GDI PrintBand apelează apoi funcția PlayEnhMetaFile, care redă EMF în contextul dispozitivului driverului imprimantei Undeva în această schemă, trebuie să existe o buclă de pagină logică pe pagina fizică Probabil că acum înțelegeți mult mai bine de ce EMF este esențial pentru sistemul de imprimare, în special în Windows Enumerarea imprimantei API-ul Win spooler include funcția EnumPrinter, care poate fi utilizată de o aplicație pentru a obține o listă de imprimante și a interoga informațiile despre imprimantă Funcția EnumPrinter este destul de complexă, are un număr mare de parametri și returnează diferite tipuri de structuri Listează imprimantele locale, furnizorii de imprimare, numele de domenii și toate imprimantele și serverele de imprimare dintr-un domeniu Funcția EnumPrinter se umple Capitolul matrice de structuri de la PRINTER INFO la PRINTER INF Cele mai complete informații despre imprimantă sunt stocate în structura PRINTER INF , care constă din de câmpuri, inclusiv câmpurile cu numele serverului, numele imprimantei, numele driverului, DEVMODE, procesorul de imprimare, tipul de date spool etc Consultați MSDN pentru mai multe informații despre EnumPrinter Următorul este un exemplu de funcție care enumerează toate imprimantele locale și conexiunile la imprimantele de la distanță void * EnumeratePr nters (steagul DW RD, numele LPTSTR, nivelul DWORD, DWORD și nImprimante) { DWORD cbNecesar; nprinters= ; EnumPr nters(steagul, nume, nivel, NULL, , & cbNeeded, & nPrinters); BYTE * pPrnlnfo = BYTE nou[cbNeeded]; lf ( pPrnlinfo ) EnumPr nters(steagul, nume, nivel, (BYTE*) pPrnlnfo, cbNeeded, & cbNeeded, & nImprimante): returnează pPrnInfo; } void L stPr nters (HWND hWnd, mesaj Int) { DWORD nImprimante; PRINTER INF * plnfo = (PRINTER INF *) EnumeratePr nters(PRINTER ENUM L CAL, NULL, , nPrinters); lf(plnfo ) { pentru (nesemnat = : wDeviceOffset ): altfel returnează NULL: } Metodele GetDriverName, GetDeviceName și GetOutputName preiau numele driverului, dispozitivului și portului de ieșire din structura DEVNAMES Valorile tipice sunt „winspool”, numele dispozitivului și „iptl:” winspool drv este un DLL client spooler Win care expune toate funcționalitățile spooler la aplicațiile Win Singurul parametru absolut necesar pentru a crea un context de dispozitiv de imprimantă este numele dispozitivului Numele șoferului este înlocuit automat; se poate renunța la numele portului de ieșire, deoarece este transmis la GDI la apelarea StartDoc; un pointer către DEVMODE este, de asemenea, opțional Dacă se transmite NULL în loc de un pointer către DEVMODE, driverul de imprimantă utilizează setările curente ale imprimantei specificate în panoul de control Pentru a crea un context de dispozitiv cu setări non-standard, trebuie să treceți o structură DEVMODE populată corespunzător Cel mai simplu mod de a crea un context de dispozitiv de imprimantă Windows fără casetele de dialog standard de imprimare este să utilizați GetDefaultPrinter și CreateDC Următorul fragment creează un context de dispozitiv pentru imprimanta implicită curentă cu setări implicite: TCHAR PrinterName[ ]: Dimensiune DWORD = ; Imprimare GDI de bază GetDefaultPrlnter(Pr nterName, & Size); HDC hDC = CreateDC(NULL, PrinterName, NULL, NULL); // Folosiți Printer DC DeleteDC(hDC); Când creați un context de dispozitiv, puteți, de asemenea, să căutați o listă de imprimante, să obțineți structura DEVMODE implicită, să o modificați și să creați un context de dispozitiv cu un nume de imprimantă și setări alese de dvs Obținerea de informații despre contextul dispozitivului imprimantei Odată ce aveți manerul de context al dispozitivului imprimantei, puteți obține informații despre context folosind funcția GetDeviceCaps Apelarea GetDeviceCaps cu indexul TEHNOLOGIE returnează tipul de imprimantă Pentru plotere, este returnat DT PLOTTER, iar pentru orice imprimante raster și chiar și imprimante PostScript, este returnat DT RASTPRINTER Vă rugăm să rețineți că unele plotere de nouă generație folosesc și tehnologia raster în loc de setul tradițional de pixuri La trecerea indecșilor LOGPIXELSX și LOGPIXELSY, funcția returnează rezoluția imprimantei, o măsură importantă folosită de aplicații la configurarea unui context de dispozitiv logic Spre deosebire de dispozitivele cu ecran, care folosesc rezoluția logică pentru a mări imaginea de pe ecran pentru ușurință de vizualizare, pe hârtie, un inch este întotdeauna egal cu exact un inch Cu toate acestea, există câteva lucruri de reținut în ceea ce privește rezoluția imprimantei Rezoluția imprimantei depinde de calitatea de imprimare selectată Driverul de imprimantă poate raporta diferite valori către GDI — x dpi, x dpi sau x dpi — în funcție de calitatea imprimării și tipul suportului din structura DEVMODE О Foaia este limitată de margini pe toate cele patru laturi (vezi Fig ) Apelurile către GetDeviceCaps cu indici HORZRES și VERTRES returnează lățimea și înălțimea nu a întregii foi, ci a zonei imprimabile A Driverul imprimantei sau firmware-ul imprimantei pot converti datele primite de la GDI la o rezoluție mai mare pentru a îmbunătăți calitatea imprimării De exemplu, un driver de imprimantă poate spune GDI o rezoluție de x dpi și scala datele la x dpi O rezoluție este importantă, dar nu singurul factor care afectează calitatea imprimării De asemenea, trebuie să țineți cont de calitatea datelor sursă, algoritmii de procesare în tonuri de gri / amestecare a culorilor, adâncimea de biți a fiecărui canal de culoare, acuratețea mecanică, compoziția chimică a cernelii, ajustarea culorii în funcție de tipul suportului etc A În Windows / , din cauza limitărilor versiunii pe biți a GDI, creșterea rezoluției are ca rezultat o scădere a dimensiunii maxime a hârtiei De exemplu, dacă un șofer raportează suport pentru dpi, maxim Capitolul dimensiunile hârtiei sunt de pixeli ( , inchi), iar dacă rezoluția este mărită la dpi, dimensiunile maxime sunt reduse la , inchi Indicii BITSPIXEL, PLANES, SIZEPALETTE și NUMCOLORS vă permit să definiți paleta și formatul de pixeli al unui dispozitiv Cu toate acestea, este puțin probabil să găsiți un driver de imprimantă cu suport pentru paletă Indicii CLIPCAPS, RASTERCAPS, CURVECAPS, LINECAPS, POLYGONALCAPS și TEXTCAPS, care sunt legați de suportul driverului de dispozitiv pentru primitivele DDI, sunt de puțină importanță pentru aplicațiile de pe sistemele familiei NT Pe aceste sisteme, motorul grafic este mult mai bun în a suporta ieșirea într-un framebuffer standard DIB și a descompune comenzile GDI în primitive Mai degrabă, aceste atribute sunt folosite de motorul grafic pentru a obține informații despre driverul imprimantei Cu toate acestea, dacă aveți probleme cu un anumit driver de imprimantă, verificați valorile acestor atribute Poate că acest lucru vă va ajuta în procesul de diagnosticare Windows / a adăugat noi indexuri SHADEBLENDCAPS și COLORMGCAPS pentru a testa capacitatea unui dispozitiv de a suporta umplerile cu gradient, amestecarea alfa și gestionarea culorilor Folosind funcțiile GDI, puteți enumera și fonturile acceptate de imprimantă Imprimantele moderne acceptă adesea fonturi care nu sunt disponibile pentru driverul de afișare Pe fig Figura - prezintă atributele contextului dispozitivului imprimantei obținute de funcția GetDeviceCaps și preluate din structura PRINTER INF completată când a fost apelat GetPrinter O versiune ușor modificată a programului Device din capitolul a fost folosită pentru a colecta informații Y' '|hpdj C ; " ІІІnit: gsh Valori Nume driver HPD eskJ et C Series s Nume imprimantă Nume partajat HP DJ C Nume port LPT : Nume driver HPD eskJ et C Series - Câmpul pszOutput conține numele dispozitivului de ieșire care primește datele generate de driverul de imprimantă Schimbând valoarea acestui câmp, puteți direcționa ieșirea către un fișier în loc de un port fizic Câmpul IpszDatatype conține tipul de date spool recomandat de aplicație; GDI și driverul de dispozitiv POT ignora valoarea acestui câmp De exemplu, pentru a utiliza caracteristici speciale ale Windows (să zicem, imprimarea mai multor pagini pe coală), este necesară spooling EMF, astfel încât GDI poate alege să folosească spooling EMF chiar dacă aplicația solicită spooling de nivel scăzut Ultimul câmp conține câteva steaguri rare utilizate de GDI și driverul de imprimantă Indicatorul DI APPBANDING spune aplicației să facă paginarea; după cum am menționat mai sus, GDI gestionează partiționarea destul de bine Indicatorul DI ROPS READ DESTINATION indică faptul că aplicația utilizează o operație raster care citește conținutul suprafeței de recepție Imprimantele raster care construiesc imaginea pe computerul gazdă suportă de obicei cu ușurință orice operație raster, dar pentru imprimantele PostScript, suportul pentru operațiunile legate de citirea de pe suprafața de recepție poate fi dificil În Windows , indicatorul DI ROPS READ DESTINATION dezactivează efectiv spoolingul EMF Funcția StartPage începe o pagină nouă pentru lucrarea de imprimare, iar funcția EndPage o încheie Mecanismul spooler necesită ca toate ieșirile GDI să fie paginate clar Comenzile grafice nu trebuie apelate înainte de primul apel la StartPage și nici între apelurile la EndPage și StartPage Din cauza negativității Capitolul În capacitățile reale de ieșire ale documentelor implementate în procesorul de imprimare și driverul de imprimantă, StartPage și EndPage definesc numai pagini logice care, la ieșire, pot fi rearanjate, împărțite în foi sau invers, scot mai multe pagini pe o singură coală fizică De obicei, pagina este redată numai după apelarea EndPage Acest lucru se datorează naturii mecanismului de spool și faptului că comenzile GDI pot scoate oriunde pe pagină, astfel încât driverul de imprimantă primește mai întâi toate comenzile de ieșire pentru pagină înainte de a decide cum să procedeze Acest proces poate fi afectat de spooler și de setările speciale de ieșire De exemplu, spooler-ul are un mod care începe tipărirea numai după ce ultima pagină a fost pusă în coadă De asemenea, trebuie să așteptați ultima pagină când imprimați în ordine inversă, imprimare broșură sau imprimare duplex Când imprimați mai multe pagini pe o singură coală, trebuie să așteptați până când toate paginile de ieșire sunt puse în coadă Funcția EndDoc încheie o lucrare de imprimare creată de funcția StartDoc Amintiți-vă că atunci când creați un context de dispozitiv de imprimantă, este obișnuit să treceți o structură DEVMODE cu toate opțiunile necesare Acești parametri pot fi modificați între pagini cu funcția ResetDC Funcției ResetDC primește un handle de context al dispozitivului și un pointer către o structură DEVMODE nouă, eventual modificată Cu această caracteristică, aplicația poate modifica dimensiunea hârtiei, orientarea sau alte setări De exemplu, Microsoft Word vă permite să scoateți fiecare pagină cu o nouă dimensiune, orientare și așa mai departe Funcția AbortDoc este concepută pentru a anula o lucrare de imprimare și a anula ieșirea acelor părți care nu au fost încă imprimate Funcția SetAbortProc atribuie o funcție de apel indirect care este apelată periodic de GDI pentru a verifica dacă lucrarea de imprimare trebuie anulată Această caracteristică este utilizată de obicei de instrumentele de anulare a imprimării din aplicații Lista - prezintă un exemplu simplu, dar realist, care demonstrează procesul de generare a lucrărilor de imprimare în GDI Lista - Generarea de lucrări de imprimare folosind GDI int nCall AbortProc: BOOL CALLBACK SimpleAbortProc(HDC hDC, int iError) { nCall AbortProc++: returnează TRUE: } void SimplePrint(int nPages) { TCHAR temp[MAX PATH]: Dimensiunea DWORD = MAX PATH: GetDefaultPrinter(temp & size): // Nume implicit al imprimantei HDC hDC = CreateDC(NULL temp NULL NULL): // DC cu parametri impliciti Imprimare GDI de bază Dacă(hDC) { nCall AbortProc = : SetAbortProc(hDC, SimpleAbortProc); DOCINFO docinfo; docinfo cbSize = sizeof(docinfo); docinfo IpszDocName = n"S'imPlePrint"); docinfo IpszOutput = NULL; docinfo IpszDatatype = JT'EMF"): docinfo fwType = ; dacă ( StartDoc(hDC și docinfo) > ) { for (int p= ; p src) delete (const source mgr *) cinfo->src: cinfo->src = NULL; } } }; GLOBAL(void) jpeg const src(j decompress ptr cinfo const unsigned char * buffer Intlen) { const source mgr * src; if (cinfo->src == NULL) // Prima dată pentru acest obiect JPEG? cinfo->src = new const source mgr; src = (const source mgr *) cinfo->src; src->Reset(buffer, len); } Clasa din Lista - decodifică imaginile JPEG în format Windows DIB și generează fișiere JPEG din imagini DIB Capitolul Lista Clasa KPicture: criptați/decriptați imaginile JPEG clasa KPicture { eliberare(vold); Int Allocatednt width, Int height, Int channels, bool bB ts=true): public: BITMAPINFO*m pBMI: BYTE*m pB ts; BYTE*m pJPEG: Int m nJPEGS ze: KP cture(): -KPIctureO; Int GetWldth(vold) const { returnează m pBMI->bmi Header biWIdth; } int GetHeight(void) const { return m pBMI->bm Header bl Înălțime; BOOL DecodeJPEGCconst vold * jpeglmage, Int jpegslze); BOOL QueryJPEG(volum constant * jpeglmage, Int jpegslze): BOOL LoadJPEGF e(const TCHAR * nume de fișier); BOOL SaveJPEGF e(const TCHAR * flleName, Int quallty): }: BOOL KPicture::DecodeJPEG(const void * jpegimage int jpegsize) { încerca { struct jpeg decompress struct dlinfo: jpeg error mgr jerr: dlinfo err = & jerr: dlinfo jpeg create decompress(); jpeg const src(&dlnfo, (const BYTE *) jpeglmage, jpegslze): dlnfo jpeg read header(TRUE); dlinfo jpeg start decompress(): Intbps = Alocare(d nfo mage w dth, dlnfo mage he ght, dlinfo out color components, true); Dacă ( m pB ts==NULL ) returnează FALSE: pentru (Int h=d nfo mage he ght-l; h>= : h ) // Inversat { // imagine Ieșire în contextul dispozitivului de imprimantă BYTE * addr = m pBits + bps * h: dinfo jpeg read scanlines(& addr, ): } dlinfo jpeg fini sh decompress(); dlinfo jpeg destroy decompress(): m pJPEG = (BYTE *) jpegimage: mjiJPEGSize = jpegsize: } captură( ) returnează FALSE: } returnează TRUE; } Lista - arată doar declarația clasei KPicture și a funcției de decodare DecodeJPEG Metoda DecodeJPEG convertește datele de imagine JPEG stocate într-un buffer de memorie direct în formatul Windows DIB inversat Metoda Allocate gestionează alocarea memoriei și populația structurii BITMAPINFO Sunt acceptate atât imaginile JPEG color pe de biți, cât și imaginile în tonuri de gri pe biți După decodare, indicatorul și dimensiunea imaginii JPEG originale sunt stocate în clasa KPicture în cazul în care driverul de imprimantă este de acord să le accepte Vă rugăm să rețineți că biblioteca JPEG a fost modificată astfel încât componentele RGB din imaginea decodificată să urmeze ordinea albastru-verde-roșu, compatibilă cu formatul DIB pe de biți CD-ul include, de asemenea, ImagePrint, un program pentru experimentarea cu decodarea, afișarea și tipărirea imaginilor JPEG În programul ImagePrint, o imagine JPEG este suportată de clasa KlmageCanvas, care este derivată din clasa KPageCanvas Funcția principală de ieșire a KlmageCanvas este de a scoate și de a imprima imagini decodificate, precum și de a tipări imaginea JPEG originală Metoda UponDrawPage este prezentată mai jos void KlmageCanvas::UponDrawPage(HDC hDC, const RECT * rcPaint, int width, int height, int pageno) { if ( (m pPicture==NULL) && (m pPicture->m pBMI==NULL) ) întoarcere: int sw = m pPicture->GetWidth(): int sh = m pPicture->GetHeight(): int dpix = sw * ONEINCH / lățime: int dpiy = sh * ONEINCH / înălțime: int dpi = max(dpix, dpiy): int dispwidth = sw * ONEINCH / dpi: int dispheight = sh * ONEINCH / dpi: SetStretchBltMode(hDC, STRETCH DELETESCANS): Capitolul int x = (lățime-dispwidth)/ : int y = (înălțime-disheight)/ : if ( StretchJPEG(hDC, x, y, dispwidth, dispheight m pPicture->m pJPEG, m pPicture->m nJPEGSize, sw, sh ) ) returnează: StretchDIBits(hDC, x, y, dispwidth dispheight O, O, sw, sh, m pPicture->m pBits m pPicture->m pBMI, DIB RGB COLORS, SRCCOPY): } ImagePrint a fost conceput pentru a fi cel mai simplu mod de a imprima fotografii, astfel încât metoda KlmageCanvas: :UponDrawPage încearcă să profite la maximum de suprafața costisitoare a suportului Acesta calculează dimensiunea maximă a unei imagini care se va potrivi pe hârtie fără distorsiuni la marginile curente Ghidat de marginile foii și simbolurile marginilor de pe ecran, puteți ajusta cu ușurință dimensiunile marginilor sau puteți comuta la o orientare diferită a foii Metoda apelează mai întâi funcția StretchJPEG și încearcă să scoată o imagine JPEG mică Dacă încercarea eșuează, trebuie transmisă o imagine BMP mare Apropo, există cel puțin un driver de imprimantă care acceptă imagini în format JPEG - acesta este driverul HP Color PostScript La ieșirea într-un fișier, veți vedea că imaginea JPEG este codificată în fișierul PostScript în date binare; aceasta duce la o reducere semnificativă a dimensiunilor fișierelor Rezultate Acest capitol reunește multe dintre subiectele abordate în carte (contexte dispozitivului, linii și curbe, umpleri, hărți de biți, fonturi, text și EMF) aplicate imprimării Ne-am uitat la arhitectura spooler, fluxul de lucru general de imprimare, funcțiile spooler API pentru preluarea informațiilor și configurarea imprimantelor, suportul de imprimare GDI și, cel mai important, implementarea API-ului Win a capabilităților de imprimare profesională în aplicații În secțiunea „Suport imprimare în programe” este prezentată o clasă generică KSurface, concepută atât pentru afișare pe ecran, cât și pentru imprimare Această clasă oferă o reprezentare completă WYSIWYG a datelor grafice într-un singur sistem de coordonate logic Secțiunea „Ieșire în contextul unui dispozitiv de imprimantă” oferă două exemple de programe non-triviale care folosesc clasele KSurface și KPageCanvas pentru a rezolva sarcini destul de reale - tipărirea textelor sursă a programului și a graficelor în format JPEG Aceasta încheie introducerea noastră în programarea grafică tradițională pentru Windows Cu toate acestea, GDI, ca orice tehnologie, continuă să evolueze Datorită accelerației hardware, în viitor, programele vor funcționa cu și mai multe culori, iar viteza lor va fi de % Rezultate nu mai sus Următorul capitol este dedicat uneia dintre domeniile dezvoltării GDI - programarea pentru DirectDraw informatii suplimentare Dacă doriți să aflați mai multe despre imprimare și spooling, consultați Microsoft DDK Veți găsi o descriere foarte detaliată a interfeței DDI, a arhitecturii spooler și a modului de scriere a minidriverelor în arhitectura UniDriver DDK include, de asemenea, codul sursă pentru driver și mini-driver, procesorul de imprimare EMF și monitorul portului Versiunile mai vechi ale Windows NT DDK includ chiar și codul sursă complet pentru driverul de imprimantă PostScript Unele probleme de imprimare sunt rezolvate prin analizarea fișierelor spool EMF Pentru informații și utilitare pentru lucrul cu metafișiere, consultați Capitolul Exemple de programe Capitolul este însoțit de câteva exemple de programe (Tabelul ) Tabelul Programe capitolul Descriere director de proiect Samples\Chapt \PrinterDevice Program pentru obținerea de informații despre funcționarea spoolerului și atributele contextului dispozitivului imprimantei Bazat pe un program similar pentru lucrul cu dispozitive cu ecran (vezi capitolul ) Samples\Chapt \Printer Program de testare pentru trimiterea datelor de nivel scăzut și EMF către spooler Ilustrează lucrul cu dialoguri de tipărire și setări de pagină, o buclă simplă de imprimare, folosind clasele KSurface și KPageCanvas, desenând linii și curbe, umplerea formelor închise și lucrul independent de dispozitiv cu hărți de biți și text Samples\Chapt \CodePrint Afișează și imprimă codul sursă al programului cu evidențiere de sintaxă în modul WYSIWYG Samples\Chapt \ImagePrint Vizualizați și imprimați grafice JPEG Programul vă permite să trimiteți imagini JPEG la imprimantă Utilizează biblioteca JPEG din directorul Samples\include\jlib Capitolul DirectDraw și Direct D Immediate Mode Interfața GDI a fost mult timp considerată principalul API de programare grafică pentru Windows Cu toate acestea, au avut loc atât de multe schimbări în lumea computerelor personale încât este timpul pentru îmbunătățiri fundamentale în GDI (deși știm că GDI este îmbunătățit treptat în fiecare nouă versiune de Windows) O versiune viitoare a GDI a primit numele de cod GDI+; va fi următoarea generație GDI de la Microsoft Conform documentației publicate de Microsoft (www microsoft com/hwdev/video/~GDInext htm), GDI+ va oferi un cadru pentru inovarea UI În special, GDI+ va permite integrarea ușoară a graficelor D și D, va simplifica procesarea imaginilor digitizate și va stabili noi standarde în calitatea graficii și performanța desktopului GDI+ va suporta caracteristici grafice non-triviale - suprapunere alfa, estompare, ferestre transparente, al doilea buffer, corecție gamma, interfață cu utilizatorul D etc Se pare că interfața GDI+ vizează în primul rând integrarea interfeței tradiționale GDI cu noile API-uri Microsoft pentru programarea jocurilor (DirectDraw și Direct D) Integrarea graficelor D și D va începe la nivelul API și se va extinde la nivelul DDI (Device Driver Interface) La nivelul DDI GDI+, accelerarea hardware completă va fi asigurată prin combinații de instrucțiuni D și D GDI+ va defini comenzi noi pentru primitivele care nu sunt acceptate de comenzile existente DirectDraw și Direct D Ei spun că DirectDraw și Direct D nu se vor mai limita la programarea de jocuri și aplicații educaționale, ci vor fi incluse în numărul de componente de bază Tehnologia COM Nents GDI Cu alte cuvinte, GDI+ ar fi GDI + DirectDraw + Direct D + altceva După cum puteți vedea, avem toate motivele să intrăm în DirectDraw și Direct D cât mai curând posibil DirectDraw este un API grafic D relativ complex, care ar dura cel puțin de pagini pentru o descriere decentă Cu toate acestea, Modul Imediat al Direct D este atât de complex încât va trebui să citiți destul de multe cărți despre grafica computerizată doar pentru a-l înțelege, cu atât mai puțin să îl utilizați eficient Acest scurt capitol poate fi considerat doar o scurtă introducere în DirectDraw și Direct D Accentul este pus pe următoarele subiecte: О familiarizarea cu conceptele, interfețele și metodele de bază pentru programatorii GDI; О dezvoltarea de clase C++ care simplifică programarea pentru DirectDraw și Direct D; Despre posibilitatea utilizării DirectDraw și Direct D în programarea „tradițională” pentru Windows Tehnologia COM Subsistemul GDI din Win API conține aproximativ de funcții care formează o ierarhie destul de complexă, fără o grupare clară La proiectarea DirectX, Microsoft a împrumutat modelul de interfață dintre aplicații și sistemul de operare din tehnologia COM Înțelegerea principiilor de bază ale COM este absolut esențială pentru a scrie programe DirectX care funcționează corect interfețe COM În tehnologia COM, metodele abstracte legate semantic sunt grupate în clase de bază abstracte, care sunt numite interfețe în terminologia COM O interfață COM, ca o clasă de bază abstractă, definește doar prototipurile tuturor metodelor de interfață la nivel sintactic și stabilește ordinea acestor metode Pentru a defini semantica acestor metode, în locul unui limbaj formal potrivit pentru verificarea automată, se folosește o notație care amintește mai mult sau mai puțin de limbajul natural - pur și simplu pentru că nu exista un candidat potrivit pentru un astfel de limbaj formal Toate interfețele COM derivă din interfața rădăcină comună IUnknown, care este definită după cum urmează: clasa INecunoscut { public: virtual HRESULT stdcall QueryInterface(REFIID riId void**ppvObject) = : Capitolul DirectDraw și Direct D Immediate Mode virtual ULONG stdcall AddRef(vold) = : virtual ULONG stdcall Release(vold) = ; Fiecare interfață COM are asociat un identificator de de biți, care de obicei conține mult mai multe informații decât ISBN-ul unei cărți, al unui număr de mașină sau al permisului de conducere Identificatorii de interfață trebuie să fie unici la nivel global, motiv pentru care sunt denumiți de obicei GUID-uri (Global Unique ID) De exemplu, GUID-ul interfeței ILIknown se numește IID IUnknown și este definit după cum urmează: DEFINE GUID(IID IUncunoscut, x , x , x , OxCO, x , x , x , x , x , x , x ); Clasele COM O interfață COM este doar o specificație abstractă Pentru ca o interfață să fie utilă, trebuie implementată într-o clasă COM O clasă COM care implementează o interfață COM trebuie să derivă din aceasta și să implementeze toate metodele acelei interfețe Următorul este un exemplu de implementare a interfeței IUnknown: clasa KUnknown : public IUnknown ULONG m nRef: // Număr de referințe public: KUNUcunoscut() m nRef = ; // În starea inițială, numărul de referințe este ULONG AddRef(vold) return++m nRef: // AddRef incrementează numărul de referințe Lansare ULONG (vold) // Eliberarea reduce numărul de referințe Dacă ( m nRef== ) // Dacă numărul de referințe ajunge la sterge aceasta: returneaza : return m nRef: HRESULT QueryInterface (ID REFIID, vold * * ppvObj) Dacă ( d == IID IUnknown) // Numai IUnknown este acceptat * ppvObj = asta: AddRef(); returnează S OK; // Returnează un pointer către obiectul curent // Crește numărul de referințe Tehnologia COM returnează E NOINTERFACE: } }: Crearea, aplicarea și ștergerea obiectelor COM sunt în general dependente de numărul de referințe Singura excepție este un singur obiect COM, care este creat ca o variabilă globală și, prin urmare, nu trebuie șters Prin urmare, un obiect COM conține de obicei cel puțin o variabilă, numărul de referințe Când este creat un obiect COM, numărul de referințe este inițializat la zero Metoda AddRef incrementează numărul de referințe; această metodă trebuie apelată atunci când este creat un nou pointer către un obiect COM Metoda Release reduce numărul de referințe și este apelată atunci când pointerul obiect COM nu mai este utilizat Dacă numărul de referințe scade la , obiectul COM corespunzător (altul decât obiectele individuale) poate fi șters Clasa Kllnknown presupune că instanțele sale sunt create pe heap cu noul operator, deci trebuie șterse cu operatorul delete Corespondența dintre apelurile AddRef și Release este extrem de importantă pentru funcționarea programelor COM Un apel suplimentar la AddRef va preveni ștergerea unui obiect COM neutilizat, ceea ce va cauza o scurgere de memorie/resurse Un apel suplimentar la Release va duce la eliminarea prematură a obiectului COM și, cel mai probabil, la erori de securitate Un obiect COM trebuie să ofere o implementare pentru toate interfețele COM din care derivă Prin urmare, trebuie să implementeze cel puțin interfața IUnknown; este probabil ca și alte interfețe să fie implementate împreună cu IUnknown Metoda QueryInterface permite clientului unei clase COM să știe dacă o anumită interfață este acceptată Interfața de interogare primește o referință la un GUID, returnează un pointer către un obiect COM convertit la tipul specific de interfață COM și o indicație de succes sau eșec În clasa KUnknown, care implementează interfața unică IUnknown, metoda Interfeței de interogare verifică dacă GUID-ul furnizat este egal cu IID IUnknown Dacă identificatorii se potrivesc, metoda returnează indicatorul this, incrementează numărul de referințe și returnează un cod S OK; în caz contrar, este returnat codul de eroare E—NOINTERFACE Pointerul returnat de funcția QueryInterface se numește indicator de obiect de interfață sau pur și simplu pointer de interfață Strict vorbind, un pointer de interfață nu este un pointer către o interfață COM, deoarece o interfață este doar o specificație, o „convenție” și nu un obiect real Pointerul de interfață indică adresa unui obiect COM; Primul cuvânt dublu de la această adresă conține un pointer către un tabel de pointeri către implementări ale metodelor virtuale definite în interfața COM Mai simplu spus, un pointer de interfață se referă la un alt pointer, care, la rândul său, se referă la o serie de implementări de metode virtuale În exemplul nostru simplu de interfață unică, indicatorul de interfață este același cu indicatorul de obiect Fiecare clasă COM are, de asemenea, un GUID care o identifică în mod unic GUID-urile clasei COM se referă de obicei la un tip CLSID separat, care este exact același format ca și GUID-ul Capitolul DirectDraw și Direct D Immediate Mode Crearea unui obiect COM Deci, avem o interfață COM și o clasă COM Cum să le folosești în alte componente? Avantajele tehnologiei COM se datorează în principal separării curate a interfețelor de implementare, ceea ce înseamnă că componentele client ale unei clase COM nu văd declarația acestei clase Dacă o declarație de clasă nu este disponibilă, nu puteți crea o instanță nouă a clasei cu operatorul nou, nu puteți șterge un obiect cu operatorul de ștergere sau nu puteți crea un obiect COM pe stivă Pentru a permite componentelor client să creeze obiecte, COM definește o interfață COM generică, IClassFactory, care este responsabilă pentru crearea obiectelor COM CreateInstance, metoda principală a IClassFactory, ia GUID-ul interfeței, creează un nou obiect COM și returnează indicatorul de interfață Clasele COM vin de obicei cu o clasă specială (numită fabrică de clase) dedicată exclusiv creării de instanțe ale clasei formale Clasele COM sunt de obicei implementate ca un DLL a cărui funcție principală de export DllGetClassObject este definită după cum urmează: STDAPI Dl GetClassObject(REFCLSID rclsld REFIID riid LPVOID*ppv); Funcția DllGetClassObject COM DLL verifică GUID-urile tuturor claselor din DLL-ul curent Când găsește o potrivire, găsește fabrica de clasă dorită și returnează un pointer către un obiect de fabrică de clasă care poate fi folosit pentru a crea una sau mai multe instanțe ale clasei COM Sistemul de operare trebuie să înregistreze noi DLL-uri COM, astfel încât să știe exact unde sunt acestea și ce clase COM implementează Modul general de a crea obiecte COM este să utilizați funcția API CoCreate-Instance Win Funcția CoCreatelnstance obține CLSID-ul clasei COM și IID-ul interfeței COM, caută în registru componenta COM necesară, o încarcă în spațiul de adrese al aplicației, găsește funcția DllGetClassObject și o apelează pentru a crea obiectul COM HRESULT Majoritatea metodelor de interfață COM returnează o valoare HRESULT semnată pe de biți Excepțiile sunt metodele AddRef și Release Tipul HRESULT constă din trei câmpuri care codifică succesul apelului de metodă, descrierea subsistemului care a eșuat și codul de stare Cel mai semnificativ bit ( ) al HRESULT conține dacă apelul a avut succes sau în cazul unei erori Biții de la la formează un cod de subsistem I-bit Biții de la la formează un cod de stare pe biți Cele mai importante informații sunt stocate în bitul cel mai semnificativ din HRESULT Semnul unui apel reușit este verificat de macro-ul REUSIT Această macrocomandă determină dacă HRESULT este o valoare nenegativă Macro-ul SUCCEEDED are o pereche de macrocomenzi FAILED care verifică dacă HRESULT este o valoare negativă Metodele COM returnează de obicei S OK ( ) la succes Tehnologia COM Cu toate acestea, nu este recomandată compararea HRESULT cu S OK Metodele DirectDraw returnează de obicei un indicator de succes DD OK ( ) Codul subsistemului, de regulă, este introdus în HRESULT numai în cazul unui apel nereușit, astfel încât programul să poată localiza eroarea într-o oarecare măsură DirectX folosește codurile de subsistem x și x Următoarele arată cum este generată valoarea HRESULT pentru erorile DirectDraw/Direct D #define FACDD x #define MAKE DDHRESULT(cod) MAKE HRESULT( FACDD cod) De exemplu, când creați o suprafață DirectDraw cu un format de pixel nevalid (cod DDERR INVALIDPIXELFORMAT), HRESULT = MAKE DDHRESULT( ) DirectX definește peste de coduri de eroare HRESULT deoarece este foarte important ca, în cazul în care apare o eroare, aplicația să poată detecta posibilele ei cauze DirectX și COM DirectX folosește zeci de interfețe și clase COM, dar canoanele modelului COM nu sunt pe deplin respectate Cea mai notabilă încălcare este că obiectele DirectX COM sunt fie create cu o funcție de export personalizată, fie construite din obiecte COM existente fără a utiliza funcția generică CoCreatelnstance Esențial pentru modul direct DirectDraw și Direct D este seria de interfețe IDirectDraw O interfață COM publicată (adică documentată oficial, distribuită și utilizată) nu poate fi modificată Pentru a include o nouă funcționalitate în el, trebuie să creați o nouă interfață De exemplu, interfața originală IDirectDraw a fost urmată de interfețele ID rectDraw , IDirectDraw și de interfața IDI finală, rectDraw?, utilizată în DirectX DirectDraw exportă o funcție specială pentru crearea unui obiect DirectDraw cu suport pentru interfața IDI rectDraw?: HRESULT WINAPI DlrectDrawCreateEx(GUID * IpGUID LPVOID * IplpDD REFIID iid, IUnknown * pUnkOuter): Primul parametru este un pointer către un GUID care identifică un dispozitiv grafic DirectDraw/Direct D la nivel de implementare hardware, implementare hardware pe al doilea monitor sau emulare software Dacă este trecut NULL, este utilizat dispozitivul de ieșire activ Constanta DDCREATE-EMULATEONLY selectează emularea software, în timp ce DDCREATE HARDWAREONLY selectează implementarea accelerată hardware Această caracteristică este utilă în special atunci când se testează un program și se diagnostichează problemele întâlnite într-o altă implementare Enumerarea implementărilor curente DirectDraw/Direct D în sistem se face prin funcția DirectDrawEnumerateEx Cu această funcție, programul dumneavoastră poate găsi o implementare care să îndeplinească cerințele sale Al doilea parametru este un pointer către o variabilă care stochează pointerul de interfață atunci când obiectul DirectDraw este creat cu succes de către funcția DirectDrawCreateEx Al treilea parametru poate fi doar egal cu IID IDirectDraw? — GUID-ul interfeței IDIrectDraw? Rezervați ultimul parametru Capitolul DirectDraw și Direct D Immediate Mode Acesta este setat să fie compatibil cu mecanismul de agregare COM și ar trebui să fie setat în prezent la NIILL Următorul este un exemplu de inițializare a mediului DirectDraw cu funcția DirectDrawCreateEx void DemoJ) rectDrawCreateEx(KLogW ndow * pLog) { IDirectDraw? *pDD=NULL: HRESULT hr = D rectDrawCreateEx(NULL, (void **) & pDD IID IDirectDraw?, NULL): dacă ( FAILED(h) ) { pLog->Log("D rectDrawCreateEx a căzut (Xx)" hr): return: } Verificați interfața (pLog, pDD, IID ID rectDraw , „IDirectDraw?”): Verificați interfața (pLog, pDD, IID ID rectDraw , „ID rectDraw ”): CheckInterface(pLog, pDD, IID ID rectDraw , „ID rectDraw ”): Verificați interfața (pLog, pDD, IID ID rectDraw, „IDirectDraw” ): Verificați interfața (pLog, pDD, IID IUnknown, „IUnknown” ): Verificați interfața (pLog pDD, IID IDDV deoPortConta ner, „IDDV deoPortContalner” ); Verificați interfața (pLog, pDD, IIDJDIrectDrawKernel „IID ID rectDrawKernel” ): Verificați interfața (pLog, pDD, IID ID rect D , „ID rect D ”): Verificați interfața (pLog, pDD, IID ID rect D „ID rect D ”): pDD->Release(): } Funcția Demo DirectDrawCreateEx apelează sistemul pentru a crea un obiect DirectDraw și a returna un pointer de interfață IDirectDraw? Dacă biblioteca DirectX este instalată pe sistem, funcția verifică suportul altor interfețe COM folosind funcția CheckInterface Funcția CheckInterface folosește QueryInterface pentru a obține un nou indicator de interfață, afișează datele în fereastra de serviciu și eliberează indicatorul În cele din urmă, Demo DirectDrawCreateEx lansează obiectul DirectDraw cu metoda Release Experimentul arată că obiectul DirectDraw creat de funcția DirectDrawCreateEx acceptă toate interfețele enumerate, cu excepția IDirect D Pe fig Figura - prezintă interfețele COM suportate de obiectul DirectDraw în formatul tradițional de diagramă COM Un obiect COM cu suport pentru toate interfețele prezentate în figură are o structură foarte complexă - în special cu suport mixt pentru interfețele DirectDraw și Direct D Din pointerii returnați de funcția QueryInterface, puteți vedea că obiectul DirectDraw nu este creat ca o singură entitate Sistemul este suficient de inteligent pentru a crea și inițializa părți ale unui obiect după cum este necesar Informații generale despre DirectDraw Orez Interfețe COM acceptate de obiectul DirectDraw După cum sa menționat mai sus, un pointer de interfață se referă la un pointer către un tabel de funcții virtuale Dacă un obiect COM este creat de compilatorul C++, compilatorul colectează tabelul de funcții virtuale în zona de date persistente a programului și generează cod pentru a insera un pointer către tabelul de funcții virtuale în obiectul nou creat Tabelul cu funcțiile virtuale ale obiectului DirectDraw este colectat în timpul execuției în segmentul global de date de citire/scriere Această abordare facilitează alegerea implementării corecte în funcție de configurația curentă a sistemului și chiar interceptarea apelurilor la metoda DirectX în scopuri de depanare Tehnica de monitorizare a interfețelor COM DirectX este descrisă în secțiunea „Monitorizarea interfețelor COM DirectDraw” din Capitolul Informații generale despre DirectDraw Deși interfețele COM se bazează pe clase de bază abstracte C++, interfețele COM sunt mult mai dificil de lucrat decât clasele C++ Interfețele COM sunt concepute în primul rând pentru a face componentele să funcționeze perfect între ele la nivel binar, nu pentru a simplifica munca programatorului la nivel de cod sursă De regulă, pentru a lucra cu interfețele COM, wrapper-urile sunt scrise sub formă de clase C ++ Interfețele COM DirectX nu sunt mai bune decât alte interfețe COM Ele conțin un număr limitat de metode cu parametri complecși combinați în structuri uriașe și zeci de tot felul de steaguri De exemplu, pentru a desena un raster pe o suprafață în GDI, puteți utiliza funcții precum PatBlt, BitBlt, StretchBlt, PlgBlt, MaskBIt, TransparentBIt și AlphaBlend DirectDraw oferă doar două metode pentru același scop: BltFast și Bit Având în vedere complexitatea descrierii complete a interfețelor DirectDraw, nu vom intra în detaliile utilizării fiecărei metode În schimb noi Capitolul DirectDraw și Direct D Immediate Mode Să ne uităm la metode în contextul claselor C++ și al exemplelor de ieșire Pentru informații complete despre orice interfață COM și metodele acesteia, consultați MSDN Interfață IDirectDraw? Lista - arată clasa KDirectDraw, care este un simplu wrapper în jurul interfeței IDirectDraw? Lista Clasă pentru lucrul cu interfața IDirectDraw #define SAFE RELEASE(inf) { if (inf) { inf->Release(): inf = NULL: }} // Wrapper pentru interfața IDirectDraw? cu clasa de suport de suprafață primară KDirectDraw protejat: IDirectDraw? * m PDD: RECT m rcDest: // Se primește dreptunghi KDDSurface m primary: Descărcare HRESULT virtuală (nulă): public: KDirectDraw(void); virtual -KDirectDraw(void) { DescarcareO: } void SetClientRect(HWND hWnd): virtual HRESULT SetupDirectDraw(HWND hTop, HWND hWnd, int nBufferCount= , bool bFullScreen = fals, int lățime=O, int înălțime=O, int bpp=O); }: KDirectDraw::KD rectDraw(void) { m pDD=NULL: } HRESULT KDirectDraw::Descărcare(void) { m primar Descărcare(); SAFE RELEASE(m pDD): returnează S OK: } void KDirectDraw::SetC entRect(HWND hWnd) Informații generale despre DirectDraw GetCl entRect(hWnd & m rcDest); ClientToScreen(hWnd, (POINT*)& m rcDest left): C entToScreen(hWnd (POINT*)& m rcDest right); ) HRESULT KDirectDraw::SetupDirectDraw(HWND hTop HWND hWnd, int nBufferCount, bool bFullScreen int lățime, int înălțime, int bpp) HRESULT hr = DirectDrawCreateEx(pDriverGUID, (void **) &m pDD, IIDJDirectDraw? NULL): dacă ( FAILED (hr ) ) întoarcere ora; dacă (bEcran complet) hr = m pDD->SetCooperativeLevel(hTop DDSCLJULLSCREEN | DDSCL EXCLUSIVE): altfel hr = m pDD->SetCooperativeLevel(hTop DDSCL NORMAL): dacă ( FAILED(hr) ) return hr: dacă (bEcran complet) { hr - m pDD->SetDisplayMode (lățime înălțime bpp ): dacă ( FAILED(hr) ) return hr: SetRect(& m rcDest lățime, înălțime): } altfel SetClientRect(hWnd): h s m primary CreatePrimarySurface(m pDD nBufferCount): dacă ( FAILED(h) ) ora de intoarcere: dacă(!bEcran complet) hr = m primary SetClipper(m pDD, hWnd): ora de intoarcere: Clasa KDirectDraw definește trei variabile: indicatorul de interfață m pDD către IDirectDraw?, dreptunghiul de destinație m rcDest și suprafața de desen primară m primary Suprafața este reprezentată de clasa KDDSurface, care va fi discutată mai jos Constructorul atribuie m pDD un pointer NULL, metoda Discharge eliberează resursele alocate (această metodă este numită în destructor) Metoda SetupDirectDraw creează un obiect DirectDraw și pregătește DirectDraw pentru randare Metoda ia șapte parametri: mânerul ferestrei de nivel superior, mânerul ferestrei copil folosind DirectDraw, numărul de buffer-uri din spate, steag-ul de ecran complet și trei numere întregi Capitolul DirectDraw și Direct D Immediate Mode numere care specifică formatul ecranului în modul ecran complet Metoda Setup-DlrectDraw creează un obiect DirectDraw apelând funcția Dl rectDrawCreateEx, care returnează un pointer de interfață către IDirectDraw? în variabila m pDD Dacă execuția funcției a avut succes, este apelată metoda IDirectDraw?::Set -CooperațiveLevel, care transmite manipulatorului ferestrei principale informații despre ce mod este necesar - ecran complet sau fereastră Programele DirectX pe ecran complet sunt de obicei clasificate ca jocuri sau educaționale De regulă, astfel de programe atribuie drepturi exclusive de a dispune de toate resursele DirectX DirectX acceptă, de asemenea, ieșire cu ferestre și chiar ieșire simultană în mai multe ferestre de către mai multe instanțe de DirectDraw Un program DirectX pe ecran complet modifică de obicei rezoluția ecranului și formatul de culoare pentru a se potrivi nevoilor sale De exemplu, programele care folosesc animație bazată pe paletă trebuie să comute ecranul la de culori; Programele care doresc să atingă performanțe maxime pot trece la un mod de rezoluție mai scăzută pentru a reduce costul memoriei video și cantitatea de date transferate Metoda SetupDi rectDraw comută modul video folosind metoda IDirectDraw::SetDisplayMode Un program pe ecran complet trebuie să enumere modurile video acceptate cu metoda IDirectDraw::Enumerate -DisplayModes, altfel încercarea de comutare poate eșua De exemplu, multe adaptoare video acceptă moduri video color pe de biți, dar nu acceptă culoarea pe de biți Metoda SetupDi rectDraw calculează și dreptunghiul suprafeței desenului și îl stochează în variabila m rcDest În modul ecran complet, dreptunghiul de recepție se potrivește întregului ecran; în modurile ferestre, zona client a ferestrei specificată de parametrul hWnd Rețineți că două mânere sunt transmise atunci când este apelat SetupDirectDraw, așa că nu ne limităm la utilizarea DirectDraw doar în fereastra principală În cele din urmă, metoda SetupDirectDraw creează suprafața grafică principală și setează decuparea pe ea Pentru a rezolva aceste probleme, avem nevoie de clasa KDDSurface Interfață IDirectDrawSurface? Toate operațiunile de ieșire din DirectDraw sunt efectuate pe suprafețe care seamănă vag cu contextele dispozitivului GDI Suprafețele DirectDraw pot reprezenta ecranul curent sau un buffer în afara ecranului din memorie Pentru primul caz, putem face o analogie cu un context de dispozitiv de ecran, iar pentru al doilea caz, cu un context de dispozitiv compatibil creat pe baza unei secțiuni DIB În prezent, pentru a lucra cu suprafețele DirectDraw, se folosește interfața IDirectDrawSurface , care conține aproximativ de metode Când vă gândiți la câte funcții GDI este transmis mânerul context al dispozitivului, este posibil să doriți să adăugați noi metode la IDirectDrawSurface pentru a ușura programarea Unele metode de bază IDirectDrawSurface vor fi descrise așa cum sunt utilizate în clasa KDDSurface Clasa KDDSurface nu este doar simplă Informații generale despre DirectDraw wrapper pentru lucrul cu interfața, dar conține și multe metode care simplifică lucrul cu suprafețele DirectDraw Lista arată declarația clasei KDDSurface, iar fragmentele de implementare vor fi furnizate după cum este necesar Lista O clasă pentru lucrul cu interfața IDirectDrawSurface? clasa KDDSurface ( protejat: ID rectDrawSurface? * m pSurface: DDSURFACEDESC m ddsd; HDC m hDC: public: KDDSurface(): virtual void Dlscharge(vold); // Eliberați resurse // înainte de apelul destructorului virtual -KDDSurfaceO // Eliberează toate resursele ( dlscha unde(); operatorIDirectDrawSurface? * & O { returnează m pSurface: } operator HDC O { returnează mJDC: Int GetWIdth(void) const returnează m ddsd dwW dth; } Int GetHeight(void) const { returnează m ddsd dwHeight; } HRESULT CreatePr marySurface(ID rectDraw * pDD Int nBackBuffer); const DDSURFACEDESC * GetSurfaceDesc(vold): virtual HRESULT RestoreSurface(void); // Recuperare // suprafeţe pierdute // Blitting în DirectDraw HRESULT SetCl pper(IDirectDraw?*pDD HWND hWnd); HRESULT BltCLPRECT prDest, ID rectDrawSurface? *psrc, Continuare & Capitolul DirectDraw și Direct D Immediate Mode Lista Continuare LPRECT prSrc DWORD dwFlags LPDDBLTFX pDDBltFx=NULL) { returnează m pSurface->Blt(prDest pSrc prSrc, dwFlags pDDBltFx); } DWORD ColorMatch (BYTE roșu, BYTE verde BYTE albastru): HRESULT Fi Culoare sau(int xO int yO int xl int yl DWORD fillcolor): HRESULT BitBltdnt x int y int w, int h IDirectDrawSurface? *psrc Steagul DWORD=O): HRESULT BitBlt(int x int y KDDSurface & src DWORD flag=O) { returnează BitBlt(xy src GetWidth() src GetHeightO src flag): } HRESULT SetSourceColorKey(culoarea DWORD): // Ieșire folosind contextul dispozitivului GDI HRESULT GetDC(void): // Obține identificatorul DC HRESULT ReleaseDC(void): HRESULT DrawBitmap(const BITMAPINFO * pDIB int dx int dy int dw int dh): // Acces direct la pixeli BYTE * LockSurface(RECT * pRect=NULL): HRESULT Uniock(RECT * pRect=NULL): int GetPitch(void) const { returnează m ddsd lPitch: } }: Clasa KDDSurface conține trei variabile: un pointer către interfața IDirect-DrawSurface , o structură care descrie suprafața și un handle de context al dispozitivului GDI Indicator către IDirectDrawSurface? returnat de sistem atunci când este creată o suprafață DirectDraw și toată interacțiunea cu suprafața are loc prin acest indicator Structura DDSCIRFACEDESC descrie formatul suprafeței Stochează cele mai importante atribute ale suprafeței—tip, lățime, înălțime, offset liniei de scanare, adresă, format de pixel și așa mai departe Fiecare suprafață DirectDraw poate avea asociat un handle de context de dispozitiv GDI, permițând redate suprafețelor DirectDraw folosind GDI Deși suprafețele DirectDraw sunt create cu o singură metodă IDirectDraw?::CreateSurface, există mai multe moduri de a crea o suprafață Clasa KDDSurface oferă metode suplimentare pentru a simplifica crearea suprafețelor Mai jos este constructorul clasei KDDSurface și metoda de creare a suprafeței primare utilizate de clasa KDirectDraw KDDSurface::KDDSurface() Informații generale despre DirectDraw m pSurface = NULL; m hDC=NULL: m nDCRef = ; memset(& m ddsd, O, sizeof(m ddsd)); m ddsd dwSize - sizeof(m ddsd): } HRESULT KDDSurface::CreatePr marySiirface(IDirectDraw? * pDD, int nBufferCount) { dacă (nBufferCount=- ) { m ddsd dwFlags - DDSD CAPS; m ddsd ddsCaps dwCaps - DDSCAPS PRIMARYSURFACE: } altfel { m ddsd dwFlags = DDSD CAPS | DDSD BACKBUFFERCOUNT; m ddsd ddsCaps dwCaps " DDSCAPS PRIMARYSURFACE | DDSCAPSJLIP | DDSCAPS COMPLEX | DDSCAPS VIDEOMEMORY; m ddsd dwBackBufferCount = nBufferCount; } return pDD->CreateSurface(& m ddsd & m pSurface NULL); } În programele DirectX pe ecran complet, adaptorul video poate suporta suprafețe simple, precum și suprafețe cu două sau trei buffere O suprafață simplă constă dintr-un singur buffer în care sunt produse toate ieșirile și al cărui conținut generează un semnal video O suprafață cu tampon dublu conține două buffere: un tampon este afișat pe ecran, iar celălalt este locul în care sunt efectuate operațiunile de ieșire Comutarea bufferelor în DirectX se realizează prin metoda IDirectDrawSurface?::Fiip Există, de asemenea, suprafețe cu trei buffere: un buffer este randat, altul așteaptă să fie randat și o a treia este locul unde se efectuează operațiunile de ieșire Suprafețele tampon duale și triple joacă un rol important în asigurarea unei ieșiri netede, fără pâlpâire Cu toate acestea, acestea sunt posibile numai în modul exclusiv de ecran complet, deoarece comutarea bufferului hardware poate fi efectuată numai pe întregul ecran, nu într-o fereastră separată Pentru a produce rezultate de înaltă calitate într-un program de fereastră DirectDraw, va trebui să utilizați o suprafață în afara ecranului și să copiați singur conținutul acesteia pe suprafața principală Metoda CreatePrimarySurface obține un pointer către interfața IDirectDraw? și numărul de tampon secundare Dacă numărul de buffer-uri din spate este , metoda setează două steaguri în structura DDSURFACEDESC pentru a crea o suprafață primară simplă; în caz contrar, sunt setate steaguri suplimentare și o valoare este atribuită câmpului pentru numărul de buffere din spate Variabila mddsd de tip DDSURFACEDESC este parțial inițializată în constructorul clasei Capitolul DirectDraw și Direct D Immediate Mode Ieșire de suprafață DirectDraw De la crearea unei suprafețe DirectDraw, puteți trece la ieșirea grafică Există trei opțiuni pentru randarea pe o suprafață DirectDraw: utilizarea metodelor IDirectDrawSurface? accelerate de hardware, GDI sau operații directe pe pixelii framebuffer-ului suprafeței Ieșire accelerată hardware Interfața IDirectDrawSurface conține doar trei metode de ieșire: Bit, BltFast și BltBatch (și ultima metodă nu este implementată) Deoarece metodele Bit și BltFast pot fi accelerate în hardware, este recomandat să le folosiți oriunde este posibil pentru a obține o performanță bună Mai jos este declararea metodei Bit HRESULT BltCLPRECT pDestRect LPDIRECTDRAWSURFACE IpDDSrcSurface LPRECT IpSrcRect DWORD dwFlags LPDDBLTFX IpDDBltFx): Metoda Bit este similară cu funcția GDI StretchBlt - de asemenea, copiază o zonă dreptunghiulară a suprafeței sursei într-o zonă dreptunghiulară a suprafeței de recepție Suprafața de destinație este determinată de indicatorul curent către IDirectDrawSurface?, iar dreptunghiul de destinație este specificat de parametrul pDestRect Sursa este determinată de parametrul IpDDSrcSurface, iar dreptunghiul sursă de parametrul IpSrcRect Parametrul dwFlags conține steaguri care controlează procesul de blitting, iar ultimul parametru conține un pointer către o structură DDBLTFX cu câmpuri de control suplimentare Cea mai simplă utilizare a funcției Bit este de a umple dreptunghiul de recepție cu o culoare uniformă (similar cu funcția PatBlt) Mai jos este metoda KDDSurface::Fi Color care încapsulează o umplere uniformă HRESULT KDDSurface::FI Culoare( nt xO, int yO, Int xl int yl DWORD fillcolor) { DDBLTFX fx; fx dwSize = sizeof(fx); fx dwFillColor = fillcolor; RECT rc = {xO yO, xl yl}; returnează m pSurface->Blt(& rc NULL, NULL DDBLT COLORFILL & fx); } Metoda Fi Col sau umple structura RECT cu cei patru parametri trecuți Suprafața și dreptunghiul sursă nu sunt necesare în acest caz Parametrul dwFlags este DDBLT COLORFILL, iar structura DDBLTFX definește practic culoarea de umplere Ieșire cu GDI Interfața DirectDraw a fost concepută pentru a permite programatorilor să se îndepărteze de GDL Cu toate acestea, încă nu puteți merge prea departe - din când în când veți avea nevoie de ajutor de la GDI Deși tehnologia DirectDraw oferă o ieșire accelerată hardware, caracteristicile sale de ieșire sunt foarte limitate În DirectX, GDI joacă încă un rol important atunci când dvs Informații generale despre DirectDraw apă text și inițializarea suprafeței cu raster Pentru a utiliza GDI pentru a lucra cu o suprafață DirectDraw, apelați metoda IDirectDrawSurface::GetDC pentru a obține mânerul de context al dispozitivului GDI Manipulatorul rezultat poate fi eliberat ulterior folosind metoda ReleaseDC Următoarele sunt metode pentru apelarea GetDC și ReleaseDC, precum și o metodă pentru desenarea DIB pe o suprafață DirectDraw folosind GDI HRESULT KDDSurface::GetDC(void) { returnează m pSurface->GetDC(&m hDC); } HRESULT KDDSurface::ReleaseDC(void) Dacă ( m hDC==NULL ) returnează S OK: HRESULT hr = m pSurface->ReleaseDC(m hDC): m hDC = NULL: return hr; } HRESULT KDDSurface:;DrawBitmap(const BITMAPINFO * pDIB Int x int y, Intw int h) dacă ( A REUSIT(GetDCO) ) { StretchDIB ts(m hDC x y, w h, O, pDIB->bmiHeader blWidth, pDIB->bm Header b Height &pDIB->bm Colors[GetDIBColorCount(pDIB)L pDIB DIB RGB COLORS SRCCOPY); returnează ReleaseDCO: } altfel returnează E-FAIL: } Metoda DrawBitmap desenează un bitmap împachetat, independent de dispozitiv, pe o suprafață DirectDraw Aceasta folosește funcția StretchDIBits, ideală pentru încărcarea bitmap-urilor pe o suprafață DirectDraw Dacă performanța este critică, funcția DrawBitmap este necesară doar pentru a încărca un bitmap pe o suprafață în afara ecranului sau texturată, care este apoi desenată pe suprafața principală folosind metoda Bit accelerată de hardware Majoritatea cărților DirectX folosesc secțiuni DDB și DIB pentru a încărca un bitmap, în combinație cu contexte de dispozitiv compatibile, ceea ce necesită crearea a două obiecte GDI Prefer să încarc un bitmap folosind DIB deoarece nu schimbă culorile (ca și în cazul DDB) și nu consumă resurse GDI suplimentare Mânerul DC returnat de metoda IDirectDrawSurface?::GetDC este interpretat ca un indicator de context al dispozitivului compatibil Dacă apelați funcția GetObjectType pe aceasta, GDI va returna OBJ MEMDC Cu toate acestea, nu trebuie confundat cu un handle de context de dispozitiv compatibil normal, deoarece nu a fost creat de funcția CreateCompati bleDC sau chiar de CreateDC Capitolul DirectDraw și Direct D Immediate Mode Acest manipulator este creat de o funcție specială a sistemului NtGdi DcGetDC Cunoscând manipulatorul DC, puteți folosi apelul GetCurrentObject(m hDC, OBJ BITMAP) pentru a selecta rasterul în context; funcția returnează mânerul secțiunii DIB Dacă apoi solicitați o descriere a secțiunii DIB folosind funcția GetObject, este completată o structură DIBSection complet normală Singura diferență este că indicatorul de date grafice se referă la un spațiu de adrese în modul kernel, ceea ce împiedică accesul acestuia în modul utilizator Cu toate acestea, această secțiune DIB este diferită deoarece suprafețele DirectDraw pot avea formate ciudate de pixeli care nu sunt formate DIB standard De exemplu, unele drivere de afișare pot accepta suprafețe RGB de biți în format - - sau suprafețe RGB de biți în format - - - Acces direct la pixeli În unele situații, chiar și o combinație de funcții Bit, BltFast și GDI nu rezolvă toate problemele Să presupunem că doriți doar să schimbați culoarea unui singur pixel pe o suprafață DirectDraw; apelarea funcției Bit sau a funcției GDI pentru aceasta ar fi prea lungă DirectDraw vă permite să accesați framebuffer-ul unei suprafețe prin blocare Metoda IDirectDrawSurface?::Lock mapează framebuffer-ul suprafeței la un bloc de memorie adresabil în modul utilizator Fixarea funcționează la fel atât pentru suprafața primară, cât și pentru suprafețele din afara ecranului Lucrul cu o suprafață fixă printr-un pointer framebuffer este aproape la fel ca lucrul cu o matrice de pixeli DIB sau o secțiune DIB, ceea ce vă permite să utilizați mulți algoritmi interesanți Fixarea suprafeței amintește de vechile programe de jocuri DOS care lucrau direct cu memoria video și obțineau performanțe ridicate pe care GDI nu le putea atinge Mai jos sunt metode de fixare și eliberare a suprafețelor BYTE * KDDSurface:;LockSurface(RECT * pRect) { dacă ( FAILED(m pSurface->Lock(pRect & m ddsd, DDLOCK SURFACEMEMORYPTR | DDLOCK WAIT NUL))) returnează NULL; altfel return (BYTE *) m ddsd lpSurface; } HRESULT KDDSurface;:Unlock(RECT * pRect) { m ddsd lpSurface = NULL: // Conținut de suprafață // devine indisponibil return m pSurface->Unlock(pRect); } Metoda LockSurfâce blochează o zonă dreptunghiulară a suprafeței apelând metoda IDirectDrawSurface?: :Lock, care face ca structura DDSURFACEDESC să fie populată Cele mai importante câmpuri ale structurii umplute conțin informații despre formatul pixelilor de suprafață, lățimea, înălțimea, offset-ul liniei de scanare și un pointer către framebuffer Ecjtn la apelarea metodei Lock, un valid Informații generale despre DirectDraw dreptunghi, indicatorul pSurface se referă la pixelul din stânga sus al acestui dreptunghi; în caz contrar, se referă la primul pixel al suprafeței Metoda Unlock eliberează suprafața blocată Pointerul returnat de metoda Lock poate fi folosit pentru a manipula direct conținutul suprafeței, dar trebuie avută o grijă extremă deoarece accesul direct nu ține cont de tăierea Accesarea pixelilor în afara limitelor va avea ca rezultat erori de protecție sau coruperea conținutului altor ferestre (dacă programul rulează în modul ferestre) Aplicația trebuie să implementeze în mod independent decuparea necesară Funcția de mai jos nu se mai limitează la simpla umplere a unei suprafețe cu o culoare uniformă BOOL PixelFII Rect(KDDSuprafață și suprafață int x int y int lățime, int înălțime, DWORD dwColor[], int nColor) { BYTE * pSurface = suprafață LockSurface(NULL): const DDSURFACEDESC * pDesc = suprafață GetSurfaceDesc(); dacă (pSurface) { int pitch = suprafață GetPitchO: int byt = pDesc->ddpfPixelFormat dwRGBBitCount / : pentru (int j= ; j GetSurfaceDesc(& m ddsd)) ) return & m ddsd; altfel returnează NULL: Informații generale despre DirectDraw DWORD KDDSurface::ColorMatch (BYTE roșu BYTE verde BYTE albastru) { lf ( m ddsd ddpfPixelFormat dwSize==O ) // Suprafața nu este inițializată GetSurfaceDesc(); // Obține descrierea suprafeței const DDPIXELFORMAT&pf=m ddsd ddpfPixelFormat: dacă ( pf dwFlags și DDPF RGB ) { // x- - - lf ( (pf dwRBitMask == x C ) && (pf dwGBitMask == OxOSEO) && (pf,dwBB tMask== x F) ) întoarcere ((roșu" )" ) | ((verde" )" ) | (albastru" ); // - - - lf ( (pf dwRBitMask == OxFSOO) && (pf dwGBitMask == x E ) && (pf dwBB tMask== x F) ) întoarcere ((roșu" )"ll) | ((verde" )" ) | (albastru" ): // x- - - lf ( (pf dwRBitMask == OxFFOOOO) && (pf dwGBitMask == OxFFOO) && (pf dwBB tMask== xFF) ) return(roșu" ) | (verde" ) | albastru; } DWORD rslt= : lf ( SUCCEDED(GetDCO) ) // Obțineți GDI DC { COLORREF vechi = ::GetPixel(m hDC ); // Salvați pixelul original SetPixel(m hDC , RGB(roșu verde albastru)); // Atribuiți ReleaseDCO; // Pixel RGB const DWORD * pSurface = (DWORD *) LockSurface(); // Fix lf (pSurface) { rslt = *pSurface; // Citiți primul dword lf ( pf dwRGBBltCount CreateC pper( , & pClIpper NULL): lf ( FAILED( hr ) ) return hr: Informații generale despre DirectDraw pClipper->SetHWnd( hWnd); m pSurface->SetClipper(pClipper); return pCl pper->Release(): } Rețineți că, după apelarea IDirectDrawSurface?::SetClirreg, suprafața primește un pointer către obiectul de tăiat, ceea ce face ca numărul de referințe al obiectului să fie incrementat Apoi este apelată metoda IDirectDrawClirreg: :Release, care eliberează referința obiectului păstrată în variabila locală a funcției Fereastra simplă DirectDraw Avem toate clasele și metodele necesare pentru a construi o fereastră DirectDraw simplă Lista arată o clasă de ferestre simplă, dar destul de completă, care acceptă DirectDraw Lista Clasă simplă de ferestre DirectDraw clasa KDDWin : public KWindow, public KDirectDraw { void OnNCPaint(void) RECT rect; GetWindowRect(m hWnd, & rect); DWORD dwColor[ ]; pentru (int i= ; i dwWidth, pDesc->dwHeight, pDesc->ddpfPi xelFormat dwRGBBi tCount pDesc->lPitch, pSurface) ; altfel strcpy(temp, "LockSurface a eșuat"); SetBkMode(m primary, TRANSPARENT); SetTextColor(m primary, RGB ddpfPixelFormat dwRGBBitCount; returnează pSurface!=NULL: } BYTE și ByteAtGntx int y) { BYTE * pPixel - (BYTE *) (pSurface + pitch * y) returnează pPixel[x]; } WORD & WordAt(int X int y) { WORD * pPixel = (WORD *) (pSurface + pitch * y): returnează pPixel[x]; } RGBTRIPLE și RGBTripleAttint x, int y) { RGBTRIPLE * pPixel = (RGBTRIPLE *) (pSurface + pitch * y); returnează pPixel[x]: Construirea bibliotecii grafice DirectDraw DWORD și DWordAtdnt x, Int y) { DWORD * pPixel = (DWORD *) (pSurface + pitch * y); returnează pPixel[x]: } BOOL SetPixel(Int x int y, culoare DWORD) { comutator (bpp) { cazul : ByteAt(x y) = (BYTE) culoare: break: cazul : cazul : WordAt(x, y) = (WORD) culoare: break: cazul : RGBTr pleAt(x, y) = * (RGBTRIPLE *) & culoare: break; cazul : DWordAt(x, y) = (DWORD) culoare: break: implicit: returnează FALSE: } returnează TRUE: } DWORD GetPixel(int x, int y): //Nu este furnizat void Linednt xO, int yO, int xl, int yl, culoare DWORD): }; În clasa KLockedSurface, o suprafață blocată este reprezentată de trei variabile: un indicator de framebuffer, un decalaj al liniilor de scanare adiacente și o adâncime a culorii pixelilor Metoda Inițialize îngheață suprafața DirectDraw și atribuie valori acestor variabile Patru metode inline (in- pe) - ByteAt, WordAt, RGBTripleAt și DWordAt - transformă framebuffer-ul într-o matrice bidimensională cu acces aleatoriu Aceste metode citesc și scriu pixeli de suprafață de , , și de biți Metoda KLockedSurface: : SetPixel oferă o ieșire generică de pixeli de suprafață, similară cu funcția GDI cu același nume Metoda KLockedSurface:- GetPixel realizează o citire generică a pixelilor Următorul este un exemplu de utilizare a clasei KLockedSurface pentru a implementa metoda SetPixel în clasa KDDSurface BOOL KDDSurface::SetPixel(int x int y, culoare DWORD) { Cadru KLockedSurface: dacă (cadru Inițializare(* asta)) { frame SetPixel(x, y, color); DeblocareO; returnează TRUE: } altfel returnează FALSE: } Pentru ca clasa să fie suficient de rapidă, ieșirea mai multor pixeli trebuie efectuată într-o singură suprafață Clasa KLockedSurface vă permite să utilizați operații logice sau alte operațiuni raster atunci când desenați pixeli Exemple: Capitolul DirectDraw și Direct D Immediate Mode ByteAt(x, y) |= (BYTE) culoare; // R MERGEPEN WordAt(x, y) „= (DWORD) culoare: // R X RPEN DwordAt(x y) = ; // R BLACK ByteAt(x y) = ((ByteAt(xl y) + ByteAt(x, y- ), (ByteAt(x+l y) + ByteAt(x y+D) / ; // Estompare Observați lipsa decupării sau a verificării limitelor în clasa KLockedSurface Se presupune că aplicația transmite coordonate pre-decupate Funcția de mai jos atrage pixeli pe suprafață void PlxelDemo(vold) { Cadru KLockedSurface: lf ( !frame In t al ze(m pr mary) ) întoarcere; pentru (Int = ; = Int d p xel neg d error neg; // Corecții pentru eroare xO ) { dx = xl - xO; nc x=bps; } altfel Construirea bibliotecii grafice DirectDraw { dx = xO - xl; nc x = -bps: } f ( yl > yO ) { dy = yl - yO: nc y = pitch; } altfel { dy = yO - yl; nc y = -pitch; } d pixel pos = inc x + inc y; // Mută x și y d error pos = (dy - dx) * : if ( d error pos = ; puncte ) // Buclă pentru pixeli de de biți { * (DWORD *) pPixel = culoare; // Ieșire pixel pe de biți dacă (eroare>= ) { pPixel += d pixel pos; eroare += d error pos; } altfel { pPixel += d pixel neg; eroare += d error neg; } } pauză; } } Metoda KLockedSurface: :Line este împărțită în două părți: faza de configurare inițială și bucla de desenare a pixelilor În faza de configurare inițială, sunt setate adresa primului pixel, numărul de pixeli de ieșire, eroarea inițială, corecțiile adresei pixelilor și erorile Bucla de ieșire acceptă toate formatele standard de pixeli de suprafață Pentru fiecare format, programul setează valoarea pixelului într-o buclă și trece la următorul pixel selectat în funcție de eroare Pentru a îmbunătăți performanța, calculul adresei pixelilor este proiectat „la loc” Practic, toate bibliotecile de grafică timpurii pentru programele de jocuri DOS au fost scrise în limbaj de asamblare Cu toate acestea, chiar și astăzi există multe cărți, Capitolul DirectDraw și Direct D Immediate Mode recomandând programarea primitivelor grafice în asamblator Dacă v-ați uitat vreodată la codul de asamblare generat de un compilator modern și sunteți sigur că puteți face mai bine - ei bine, încercați dar fiți conștienți de faptul că codul de asamblare neoptimizat vă va încetini programul Dacă doriți să vedeți de ce este capabil compilatorul, generați liste cu comenzi C/C++ și cod de asamblare Iată cum arată bucla de ieșire a pixelilor de de biți, procesată de compilatorul VC : // eax culoare // puncte ebx // eroare ecx // edxpPixel // esi d error pos // editați d error neg // ebp d pixel neg test ebx ebx if ( puncte Buffer; pentru (nesemnat = ; rdh nCount; ++) { \ FI Col sau(pRect->stânga pRect->sus pRect->r ght preRect-> jos culoare); prerect++; } șterge[] (BYTE*) returnează TRUE; Capitolul DirectDraw și Direct D Immediate Mode GDI conține o mare varietate de funcții de regiune care vă permit să afișați forme geometrice simple și combinațiile acestora, să creați trasee închise și chiar contururi de text În programele DirectDraw, se recomandă să vă bazați pe suportul regiunilor din GDL Dacă performanța este deosebit de importantă, datele de regiune pot fi calculate în avans și stocate în cache Metoda KDDSurface::Fi Rgn primește mânerul obiectului regiunii GDI; împarte regiunea într-o serie de dreptunghiuri (structură RGNDATA) folosind funcția Get-RegionData GDI și apoi pictează fiecare dreptunghi cu o culoare uniformă folosind metoda IDirectDrawSurface?::Blt, având în vedere starea obiectului de tăiere DirectDraw curent De asemenea, este posibilă o altă implementare - convertiți lista de tăiere a obiectului de tăiere DirectDraw curent într-o regiune GDI, obțineți intersecția acesteia cu regiunea de ieșire, creați o nouă listă de tăiere și scoateți rezultatul folosind Bit Dezavantajul acestei soluții este că trebuie să creați un al doilea obiect de tăiere DirectDraw și să comutați între obiectul de tăiat și suprafață Următorul exemplu desenează o elipsă uniformă pe o suprafață DirectDraw: voidRegionDemo(void) { HRGN hRgn = CreateEl IpticRgriIndirect(& m rcDest); lf(hRgn) { m primary FillRgn(hRgn, m primary ColorMatchCOxFF, OxFF )): DeleteObject(hRgn); } } Pe fig Figura - prezintă o fereastră copil MDI cu pixeli, linii și o elipsă desenată folosind DirectDraw Orez Pixeli, linii și forme pe o suprafață DirectDraw Construirea bibliotecii grafice DirectDraw tăiere Suprafețele DirectDraw acceptă decuparea folosind obiecte de tăiere DirectDraw create prin metoda IDirectDraw::CreateClipper Decuparea Obiectele DirectDraw se împart în două categorii: cele asociate unei ferestre și cele create pe baza listei de tăiere Când un obiect de tăiere este asociat cu o fereastră cu metoda IDirectDrawClipper::SetHWnd, sistemul de operare face ceva magic pentru a se asigura că obiectul de tăiat este întotdeauna sincronizat cu regiunea de actualizare a ferestrei particulare Prin urmare, ieșirea pe o suprafață DirectDraw cu un obiect de tăiere atașat poate fi limitată la porțiunea vizibilă a zonei client Am văzut deja cum obiectele de tăiere asigură că metoda Bit funcționează corect în modul ferestre O aplicație poate, de asemenea, să manipuleze direct un obiect de tăiere DirectDraw modificând conținutul listei sale de tăiere, care este o structură normală RGNDATA GDI Documentația DirectX presupune că programatorii DirectX sunt destul de versați în programarea GDI, așa că nu spune prea multe despre cum să lucrezi corect cu listele tăiate Următoarea funcție și clasă asociază un obiect de regiune GDI cu un obiect de tăiere DirectDraw BOOL SetCl pReg on(IDirectDrawClipper * pClipper HRGN hRgn) { RGNDATA * pRgnData = GetCl pReglonData(hRgn): if (pRgnData==NULL) returnează FALSE: HRESULT hr = pCl pper->SetClipList(pRgnData ): ștergeți (BYTE *) pRgnData: return SUCCEEDED(h); } clasa KRgnCUpper ( IDirectDrawClipper * m pNew; IDirectDrawClipper * m p d: ID rectDrawSurface *m pSrf; public: KRgnCl pper(ID rectDraw? * pDD, IDirectDrawSurface? * pSrf HRGN hRgn) { pDD->CreateC pper( & m pNew, NULL): // Creați obiect de tăiere SetCl pReg on(m pNew hRgn):// Obțineți lista tăiate // după regiune m pSrf = pSrf: pSrf->GetCl pper(& m p d): // Obține vechiul obiect de tăiere pSrf->SetCl pper(m pNew); // Înlocuiește cu un nou obiect de tăiere Capitolul DirectDraw și Direct D Immediate Mode } -KRgnCl pper() { m pSrf->SetC pper(m p d); // Restaurați vechiul obiect de tăiere m p d->Release(); // Eliberează vechiul obiect de tăiere m pNew->Release(); // Eliberează noul obiect de tăiere } }: Funcția SetClipReg populează lista de tăiere a unui obiect de tăiere DirectDraw cu datele unui obiect de regiune GDI Apelează funcția GetRegionData GDI de pe handle-ul regiunii pentru a obține datele După cum am menționat mai sus, deoarece datele regiunii sunt de dimensiune variabilă, funcția trebuie apelată de două ori - mai întâi obțineți dimensiunea datelor, alocați memorie și apoi obțineți datele în sine Clasa KRgnClirreg înlocuiește obiectul de tăiere asociat cu o suprafață DirectDraw cu un nou obiect de tăiere generat din datele obiectului regiune GDI Constructorul creează un nou obiect clip, își populează lista de clipuri cu datele regiunii GDI și înlocuiește obiectul clip curent asociat cu suprafața Toate operațiunile de ieșire ulterioare folosesc noul obiect de tăiere Destructorul restaurează obiectul de tăiere original și eliberează resursa Funcția de mai jos folosește clasa KRgnClirreg pentru a umple zonele vold ClipDemo(void) { HRGN hllpdate = CreateRectRgn(O , ): GetUpdateRgn(m hWnd, hUpdate FALSE); // Regiunea actualizată OffsetRgn(hUpdate, m rcDest left, m rcDest top); // Coordonatele ecranului HRGN hEHIpse = CreateEl pt cRgn(m rcDest left- , // Elipsă mare m rcDest top- m rcDest rlght+ , m rcDest bottom+ ); CombineRgn(hElipse, hElipse, hActualizare, RGN AND); // Regiunea ȘI elipsa actualizată DeleteObject(hUpdate); KRgnClIpper cilpper(m pDD, m pr mary, hellIpse); DeleteObject(hEl pse); m pr mary FI Culoare(m rcDest left- , m rcDest top- , m rcDest rlght+ , m rcDest bottom+ m pr mary ColorMatch( , , OxFF)); } Funcția ClipDemo solicită regiunea de actualizare a ferestrei curente și o convertește din coordonatele clientului în coordonatele ecranului, așa cum este cerut de DirectDraw Funcția creează apoi o regiune eliptică care este mai mare decât zona client, își găsește intersecția cu regiunea actualizată și definește o nouă regiune de tăiere Folosește metoda KDDSurface::Fi Color Construirea bibliotecii grafice DirectDraw Aceasta este pentru a umple o zonă mai mare decât partea client a ferestrei, dar tăierea limitează rezultatul atât la limitele elipsei, cât și la regiunea care este actualizată Suprafețe în afara ecranului După cum arată metoda KDDSurface::DrawBitmap, cel mai simplu mod de a desena un bitmap pe o suprafață DirectDraw este să folosiți funcții GDL scrieți o cantitate destul de mare de cod, iar acest lucru va duce la performanță lentă și la pierderea tuturor avantajelor DirectDraw Abordarea corectă a rasterizării în DirectDraw profită atât de GDI, cât și de DirectDraw Mai întâi, rasterul este încărcat pe suprafața în afara ecranului folosind GDI, apoi este afișat pe suprafața principală folosind DirectDraw Crearea suprafeței în afara ecranului și încărcarea rasterului sunt furnizate de clasa KOffscreenSurface, care derivă din KDDSurface typedef enumerare mem default mem system, mem nonloca video mem loca video clasa KOffscreenSurface : public KDDSurface { public: HRESULT CreateOffScreenSurface(IDirectDraw * pDD int lățime, int height int mem=mem default): HRESULT CreateOffScreenSurfaceBpp(IDirectDraw * pDD int lățime, int înălțime int bpp, int mem=mem default): HRESULT CreateBitmapSurface(IDirectDraw * pDD, const BITMAPINFO * pDIB, int mem=mem default): HRESULT CreateBitmapSurface(IDirectDraw * pDD const TCHAR *pFileName int mem=mem default): }: const DWORD MEMFLAGSE] = { DDSCAPS-SYSTEMMEMORY DDSCAPS-NONLOCALVIDMEM | DDSCAPSJ/IDEOMEMORY, DDSCAPS LOCALVIDMEM | DDSCAPS VIDEOMEMORY }: HRESULT KOffscreenSurface::CreateOffScreenSurface(IDirectDraw * pDD, int lățime, int înălțime int mem) Capitolul DirectDraw și Direct D Immediate Mode { m ddsd dwFlags = DDSD CAPS | DDSD HEIGHT | DDSD WIDTH: m ddsd ddsCaps dwCaps = DDSCAPS OFFSCREENPLAIN | DDSCAPS DDEVICE | MEMFLAGS[mem]: m ddsd dwWidth = lățime: m ddsd dwHeight = înălțime: returnează pDD->CreateSurface(& m ddsd, & m pSurface, NULL); } HRESULT KOffScreenSurface::CreateBitmapSurface(IDirectDraw * pDD const BITMAPINFO * pDIB, int mem) { dacă (pDIB==NULL) returnează E-FAIL: HRESULT h = CreateOffScreenSurface(pDD, pDIB->bmiHeader biWidth, abs(pDIB->bmiHeader biHeight) mem): dacă ( FAILED(hr) ) return hr: returnează DrawBitmap(pDIB, O, O, m ddsd dwWidth, m ddsd dwHeight): } Metoda CreateOffScreenSurface creează o suprafață DirectDraw în afara ecranului, adică o suprafață care este stocată în memorie, dar nu este afișată pe ecranul monitorului Memoria pentru suprafața în afara ecranului poate fi alocată din memoria sistemului, memorie video locală sau non-locală, în funcție de steaguri din câmpul ddsCaps dwCaps Memoria de sistem este abundentă, deoarece capacitatea sa este limitată doar de dimensiunea fișierului de paginare a sistemului Memoria video non-locală se referă la memoria controlată de AGP (Advanced Graphics Port), un mecanism care asigură copierea accelerată a datelor în memoria video În comparație cu memoria de sistem, memoria non-locală este o resursă mai limitată, dar poate fi accesată mai rapid Memoria video locală este cea mai scumpă și cea mai rară dintre toate tipurile de memorie Apropo, cu acces direct la pixeli din aplicație, memoria video locală este cea mai lentă, deoarece este situată „mai departe” de procesor Ultimul parametru la CreateOffScreenSurface indică de unde este alocată memoria de suprafață Spre deosebire de suprafața primară, atunci când creați suprafețe în afara ecranului, trebuie să specificați dimensiunea exactă a acestora Metoda CreateOffScreenSurfaceBpp, care nu este implementată aici, vă permite să creați o suprafață în afara ecranului cu un format de pixel dat Prima metodă CreateBI tmapSurface ia ca intrare un raster DIB împachetat Acesta creează o suprafață în afara ecranului în funcție de dimensiunile bitmap-ului și apoi copiază bitmap-ul pe suprafață folosind GDI A doua metodă Create-BitmapSurface, care nu este prezentată aici, creează o suprafață și încarcă un bitmap în ea dintr-un fișier extern Ambele metode folosesc DIB, care economisește resurse în comparație cu hărțile de biți DDB și secțiunile DIB care sunt foarte recomandate în literatura DirectX Construirea bibliotecii grafice DirectDraw Odată ce un bitmap a fost încărcat pe o suprafață în afara ecranului, acesta poate fi copiat pe o altă suprafață folosind metoda IDirectDrawSurface?::Blt Clasa KDDSurface conține două metode BitBlt care sunt simple wrappers pentru metoda Bit pentru a face apelurile mai mult ca apelurile de funcție GDI Mai jos este una dintre aceste cochilii HRESULT KDDSurface::BitBlt(int x Int y, Int w, Int h, IDirectDrawSurface? *psrc steag DWORD) { RECT rc = { x y, x+w y+h}; returnează m pSurface->Blt(& rc, pSrc NULL, flag NULL): } Suport pentru transparență prin taste de culoare Metoda IDirectDrawSurface?: :Blt acceptă desenarea de hărți de biți transparente folosind tastele de culoare Cheia de culoare este un atribut al unei suprafețe DirectDraw și poate fi setată atât pentru suprafața sursă, cât și pentru suprafața destinație O cheie de culoare, care poate fi fie o singură culoare, fie o gamă de culori, este definită de structura DDCOLORKEY Următoarea este metoda SetSourceCol orKey a clasei KDDSurface care setează cheia de culoare sursă folosind o singură culoare fizică HRESULT KDDSurface::SetSourceCologKey(culoarea DWORD) ( tasta DDCOLORKEY; key dwColorSpaceLowValue = culoare; key dwColorSpaceHIghValue = culoare: returnează m pSurface->SetColorKey(DDCKEY SRCBLT, & key); } Pentru a copia o suprafață bitmap în afara ecranului cu o cheie de culoare sursă, apelați metoda Bit cu indicatorul DDBLT KEYSRC Aceasta copiază numai acei pixeli ale căror valori sunt diferite de cheia de culoare sursă Tastele de culoare de destinație sunt, de asemenea, acceptate în DirectDraw Font și text DirectX, ca API simplu, de nivel scăzut, optimizat pentru performanță maximă, nu are suport încorporat pentru fonturi sau text Chiar și implementarea Windows a OpenGL funcționează cu fonturi prin extensii speciale Dacă utilizați facilități GDI pentru operațiunile cu fonturi și redarea textului pe suprafețele DirectDraw, ați putea lua în considerare și utilizarea unui context de dispozitiv GDI Cu toate acestea, în jocuri și aplicații care necesită performanțe ridicate, utilizarea funcțiilor GDI lente este inacceptabilă În jocuri, o altă opțiune este adesea întâlnită - programul construiește un raster în avans cu full Capitolul DirectDraw și Direct D Immediate Mode un set de glife necesare (să-i spunem un raster de font) În loc de font, programul funcționează cu un raster, iar rezultatul textului se reduce la copierea fragmentelor unui raster de font Partea slabă a acestei soluții este lipsa de flexibilitate, deoarece programul folosește un set limitat de fonturi de o anumită dimensiune Soluția optimă, ca și înainte, combină două abordări - GDI și hărți de biți font Ideea este de a construi în mod dinamic hărți de biți de font pentru un anumit tip de caracter și dimensiune, apoi să folosiți metodele DirectDraw pentru a desena text din hărțile de biți ale fontului Ecranele cu fonturi sunt construite numai atunci când aplicația este încărcată, ceea ce extinde alegerea fonturilor și dimensiunilor fără a pierde prea mult performanța Bitmap-urile fonturilor pot fi chiar stocate în cache în fișiere bitmap de pe disc și încărcate pe suprafețe în afara ecranului (probabil memorie video locală pentru performanță maximă) folosind metoda Bit accelerată de hardware Lista - arată clasa KDDFont, care acceptă lucrul cu hărți de biți de fonturi generate dinamic pe suprafețe în afara ecranului Lista Clasa KDDFont: lucrul cu hărți de biți de font dinamic și ieșire de text șablon clasa KDDFont : public KOffScreenSurface { int int m offset [MaxChar]: m advance[MaxChar]: // Metric A // A + B + C int m pos [MaxChar]: // Poziție orizontală int m width [MaxChar]: // - min(A, ) + B - min(CO) unsigned m firstchar: int m nChar: public: HRESULT CreateFont(IDirectDraw? * pDD const LOGFONT & lf primul caracter nesemnat ultimul caracter nesemnat COLORREF crColor): int TextOut(IDirectDrawSurface? * pSurface int x int y const TCHAR * mizerie int nChar=O): ); template HRESULT KDDFont ::CreateFont(IDirectDraw? * pDD const LOGFONT & lf primul caracter nesemnat lastchar nesemnat COLORREF(crColor) { m firstchar = firstchar: mjiChar = lastchar - firstchar + : if ( mjiChar > MaxChar ) returnează E-INVALIDARG: HFONT hFont = CreateFontIndirect(&lf): Construirea bibliotecii grafice DirectDraw if (hFont==NULL) returnează EJNVALIDARG; HRESULT oră; ABC abc[MaxChar]; int inaltime; { HDC hDC = :;GetDC(NULL); dacă(hDC) { HGDIOBJ hold = SelectObject(hDC hFont); TEXTMETRIC tm; GetTextMetrics(hDC &tm); inaltime = tm tmHeight; if ( GetCharABCWidths(hDC firstchar, lastchar abc) ) hr = S OK; altfel hr = E-INVALIDARG; SelectObject(hDC Hold); ::ReleaseDC(NULL hDC); } } dacă ( A REUSIT(h) ) { int lățime = ; pentru (int = ; int KDDFont ::TextOut(IDirectDrawSurface? * pDest, int x, int y, const TCHAR * mizerie int nChar) { dacă ( nChar m nChar) ) ch = ; RECT dst = { x + m offset[ch], y x + m offset[ch] + m width[ch], y + GetHeightO }; RECT src = { m pos[ch], m pos[ch] + m width[ch], GetHeightO }; pDest->Blt(& dst, m pSurface, & src, DDBLTJCEYSRC NULL); x += m advance[ch]; întoarce x; Clasa KDDFont este proiectată să accepte fonturi generice furnizate de GDI Mai precis, acceptă fonturi monospațiate și proporționale și valori de text ABC Clasa KDDFont adaugă noi câmpuri la clasa KOffscreenSurface Matricea m offset stochează valorile A ale tuturor Construirea bibliotecii grafice DirectDraw fov; tabloul m advance specifică decalajele următoarelor caractere; matricea m pos conține poziția orizontală a fiecărui glif de pe suprafață, iar matricea m width deține lățimile glifelor Clasa convertește spațierea dintre caractere a unui font într-un bitmap de font (primele și ultimele caractere ale spațierii sunt stocate în variabile separate) Numărul maxim de caractere este determinat de parametrul șablon Metoda KDDFont::CreateFont inițializează un bitmap de font folosind datele inițiale — un pointer către un obiect IDirectDraw?, o structură LOGFONT GDI, spațierea caracterelor și culoarea textului Acesta creează un font logic GDI din structura LOGFONT și interogează valorile ABC pe baza cărora sunt populate patru matrice În urma calculelor, se determină lățimea și înălțimea bitmap-ului fontului, după care se creează o suprafață DirectDraw în afara ecranului Ștergerea rasterului și afișarea tuturor glifelor din acesta se face folosind GDL Din păcate, nu putem converti toate caracterele de spațiere într-un șir și le putem scoate într-un singur apel de funcție, deoarece caracterele din șir se pot suprapune orizontal Fiecare caracter este desenat separat la o poziție raster precalculată Caracterele sunt afișate pe un fundal negru, iar negrul este atribuit ca cheie de culoare a fontului Metoda KDDFont: :TextOut folosește conținutul unei suprafețe bitmap de font pentru a scoate un șir de caractere pe o suprafață DirectDraw Pentru a căuta glife și a le alinia într-un șir, sunt folosite patru matrice, stocate în variabilele clasei KDDFont Fiecare caracter este desenat în modul transparent cu cheia de culoare a sursei (suprafața fontului) folosind metoda IDirectDrawSurface?::Blt Metoda TextOut scoate text cu cheia de culoare specificată atunci când a fost creată suprafața fontului Clasa KDDFont poate fi extinsă cu metode care schimbă culoarea textului sau afișează textul cu efecte speciale Suprafața fontului poate fi stocată într-un raster și, ulterior, se poate face fără apeluri repetate la GDI Sunt posibile și alte îmbunătățiri, cum ar fi separarea glifelor cu spațiere suplimentară Sprites Multe programe de joc se bazează pe utilizarea bitmap-urilor simple și transparente Rasterele transparente, numite spracts în jocuri, înfățișează diferite obiecte în mișcare, la contactul cărora apar anumite evenimente în joc Jocurile folosesc tastatura, mouse-ul sau alt dispozitiv de intrare pentru a controla mișcarea sprite-urilor Următorul este un pseudo-program de joc DirectDraw care ilustrează rezultatul bitmaps-urilor, sprite-urilor și textului pe o suprafață DirectDraw clasa KSprlteDemo : KMDIChlId public public KDirectDraw { KOffScreenSurface m background; POINT m backpos: KOffScreenSurface m sprite: POINT m sprițepos: KDDFont m font: HINSTANCE m hlnst; Capitolul DirectDraw și Direct D Immediate Mode HWND mJiTop: vold OnDraw(vold): vold OnCreate(vold); vold MoveSpritednt dx, Int dy) { m sprițepos x += dx * ; m spritepos y += dy * ; OnDraw(): } LRESULT WndProc(HWND hWnd UINT uMsg WPARAM wParam LPARAM IParam) { intrerupator! uMsg) { caz WM PAINT: OnDraw(): Val dateRect(hWnd NULL); întoarce ; caz WM-KEYDOWN: comutator (wParam) { caz VK HOME : MoveSprite(-l - ): break; cazul VKJJP : MoveSpr te( - ); pauză; caz VK PRIOR: MoveSprite(+l - ); pauză; caz VK LEFT : MoveSpr te(-l, ); pauză; caz VK RIGHT: MoveSpr te( ); pauză; cazul VK END ; MoveSprite(-l, ); pauză; caz VK DOWN: MoveSprite( , ); pauză: caz VK-NEXT : MoveSpr te( ); pauză; } întoarce ; caz WM-CREATE: m hWnd = hWnd; nCreate(): // Continuă Mod implicit: returnează KMDIChlld::WndProc(hWnd, uMsg, wParam IParam); } } public: KSpriteDemo(HMODULE hModule HWND hTop) { m sprițepos x = ; m spr tepos y = : m backpos x = ; m backpos y = ; Construirea bibliotecii grafice DirectDraw m hlnst = hModul; m hTop = hTop; } }: Clasa KSprlteDemo este declarată ca derivă din clasele KMDIChi d (suport pentru fereastră copil MDI) și KDirectDraw (suport DirectDraw) Variabilele m background și m backpos sunt destinate să controleze bitmap-ul de fundal încărcat pe suprafața DirectDraw în afara ecranului Dimensiunile rasterului de fundal pot depăși dimensiunile ferestrei, caz în care fereastra derulează în rasterul de fundal Variabilele m sprite și m spri țepos sunt folosite la desenarea planului peste scena de fundal Variabila m font stochează o instanță a clasei KDDFont Metoda OnCreate inițializează bitmap-ul de fundal, sprite-ul și fontul boolean Metoda OnDraw desenează o imagine într-o fereastră, iar metoda MoveSprite oferă controlul zborului cu tastatură Mai jos este implementarea metodei OnCreate void KSprlteDemo;;OnCreate(void) { if ( REUSIT(SetupDirectDraw(m hTop, m hWnd false)) ) { BITMAPINFO * pDIB = LoadBMP(m hInst MAKEINTRESOURCE(IDB NIGHT)); lf (pDIB) m background CreateBItmapSurface(m pDD pDIB); pDIB = LoadBMP(m hInst MAKEINTRESOURCE(IDB PLANE)); dacă (pDIB) { m spri te CreateBItmapSurface(m pDD pDIB): m sprite SetSourceColorKey( ); // Negru } LOGFONTlf; memset(&lf sizeof(lf)); lf IfHeight = - ; If lfWeight = FW BOLD; lf Inflatal = ADEVĂRAT; lf IfQuality = ANTIALIASED-QUALITY; tcscpy(lf IfFaceName „Times New Roman”); m font CreateFont(m pDD lf ' ' x F, RGB(OxFF OxFF )): } else { MessageBox(NULL T(„Nu se poate inițializa DirectDraw”) T(„KSpriteDemo”) MB OK); CloseWindow(mJiWnd); } } Metoda OnCreate inițializează mediul DirectDraw în modul ferestre apelând metoda KDirectDraw: :SetupDirectDraw Apoi încarcă imaginea de fundal din resursă în format bitmap DIB împachetat și inițializează imaginea de fundal Capitolul DirectDraw și Direct D Immediate Mode raster nou Sprite-ul este, de asemenea, încărcat din resursă, iar negrul este atribuit ca cheie de culoare sursă Suprafața raster a fontului este inițializată cu o structură LOGFONT reprezentând un font italic de de puncte În continuare este implementarea metodei OnDraw void KSpriteDemo::OnDraw(void) { SetClentRect(mJiWnd): int dy = (m rcDest bottom - m rcDest top - m background GetHeight())/ ; // Zona redată este în afara limitelor imaginii de fundal dacă (dy> ) { Culoare DWORD = m primary ColorMatch( x , x ); m primary Fi Col sau(m rcDest left, m rcDest top m rcDest dreapta m rcDest top + dy culoare); // In capul barului culoare = m primary ColorMatch( x x ); m primary FillColor(m rcDest left m rcDest bottom - dy- , m rcDest dreapta m rcDest bottom culoare); // banda de jos } altfel dy = ; // Desenați imaginea de fundal // Dacă marginea dreaptă a sprite-ului este în afara ferestrei // mutați fundalul la stânga while ( (m sprițepos x + m sprite GetWidth() + m backpos x) > (m rcDest right - m rcDest left) ) m backpos x -= ; // Dacă marginea din stânga a sprite-ului este în afara ferestrei // mutați fundalul la dreapta în timp ce ( (m sprițepos x + m backpos x) QueryInterface( IID ID rect D (vold **) & m pD D ): Dacă ( FAILED(hr) ) ora de intoarcere: CLSID lldDevice = IID ID rect DHALDev ce: // Creați Z Buffer hr = m zbuffer CreateZBuffer(m pD D m pDD, lldDevice, lățime, înălțime): Dacă ( FAILED(h) ) { lldDevice » IID ID rect DRGBDev ce: hr » m zbuffer CreateZBuffer(m pD D m pDD, lldDevice, lățime, înălțime): } Continuare Capitolul DirectDraw și Direct D Immediate Mode Lista Continuare if ( FAILED(hr) ) return hr; // Atașați Z Buffer la suprafața de fundal hr "m backsurface Attach(m zbuffer); dacă ( FAILED(h) ) întoarcere ora; hr " m pD D->CreateDevice( iidDevice, m backsurface & m pD DDevice ); dacă ( FAILED(h) ) întoarcere ora; { D DVIEWP RT vp - { latime înălţime (plutitor)OO (plutitor)lO }; returnează m pD DDevice->SetViewport( &vp ); } } Clasa KDirect D adaugă cinci variabile la KDirectDraw: un pointer către un obiect Direct D , un pointer către un obiect Direct DDevice , un buffer de fundal, un buffer Z și un steag boolean Procedura de inițializare începe prin configurarea mediului DirectDraw apelând KDirectDraw: -SetupDirectDraw După inițializarea DirectDraw, funcția verifică modul video curent și, dacă folosește o paletă, returnează un cod de eroare Programele Direct D funcționează cel mai bine în modurile High Color și True Color; Modul cu palete este de asemenea acceptat, dar are prea multe restricții Ieșirea Direct D este extrem de complexă, așa că toate operațiunile trebuie efectuate pe o suprafață de fundal În modul ecran complet, suprafețele cu două sau trei buffere pot fi utilizate, în timp ce în modul fereastră, ieșirea este efectuată pe o suprafață de fundal separată Funcția creează o suprafață în afara ecranului care are aceeași dimensiune cu zona client a ferestrei Pentru a crea un Z-buffer pentru o suprafață de ieșire, mai întâi trebuie să obțineți un pointer către interfața IDirect D a obiectului DirectDraw creat de funcția DirectDrawCreateEx Z-buffer-ul este, de asemenea, o suprafață în afara ecranului, cu excepția faptului că funcția IDirect D : -EnumZBufferFormats este utilizată pentru a obține informații despre formatele Z-buffer acceptate de dispozitivul curent Funcția încearcă să creeze un buffer Z pentru un dispozitiv accelerat de hardware, dar dacă nu reușește, trece la un dispozitiv emulat prin software Z-bufferul creat trebuie atașat la suprafața de fundal Partea finală a metodei KDirect D: -SetupDirectDraw creează un obiect Direct- DDevice pentru suprafața de fundal și definește portul de vizualizare pentru dispozitiv Obiectul Direct DDevice oferă o interfață pentru randarele D implementate pentru suprafețele compatibile cu SD Primele patru câmpuri ale ferestrei de vizualizare definesc aria dreptunghiulară a suprafeței în care se realizează ieșirea; ultimele două câmpuri definesc intervalul de valori din Z-buffer Modul Direct D Direct Redimensionarea unei ferestre În modul ferestre, suprafața de fundal și Z-buffer-ul sunt create în funcție de dimensiunea zonei client a ferestrei Cu toate acestea, atunci când utilizatorul redimensionează fereastra, aceste suprafețe trebuie recreate pentru noile dimensiuni Cea mai simplă soluție este să distrugi toate obiectele DirectDraw/Direct D și să le creezi de la început Următoarele sunt metode pentru ștergerea și re-crearea obiectelor de mediu Direct D HRESULT KDirect D::Descărcare (nulă) { SAFE RELEASE(m pD DDevice): m backsurface Discharge(): m zbuffer Descharge(): SAFE RELEASE(m pD D): returnează KDIrectDraw:;D scharge(): } HRESULT KDirect D::ReCreate(HINSTANCE hlnst HWND hTop HWND hWnd) { dacă ( FAILED( nD charge()) ) returnează E FAIL: if ( FAILED( DeschargeO ) ) // Eliberați toate resursele returnează E FAIL: SetClientRect(hWnd): HRESULT hr = SetupDirectDraw(hTop hWnd false m rcDest right - m rcDest left m rcDest bottom - m rcDest top): dacă ( A REUSIT(h) ) return OnInit(hlnst): altfel întoarcere ora; } HRESULT KDirect D::OnResize(HINSTANCE hlnst int lățime int înălțime HWND hTop HWND hWnd) { dacă ( ! m bReady ) returnează S OK; dacă (lățimea ==(m rcDest right - m rcDest left) ) if ( heighte"(m rcDest bottom - m rcDest top) ) return S OK; returnează ReCreate(hInst hTop hWnd): Capitolul DirectDraw și Direct D Immediate Mode Metoda de descărcare eliberează toate resursele asociate cu obiectul KDirect D Metoda Recreate apelează Discharge pentru a elibera toate resursele și apoi creează un nou mediu Direct D apelând SetupDirectDraw Metoda OnSize apelează ReCreate atunci când fereastra este redimensionată Retragere în doi pași Când se utilizează suprafața de fundal, imaginea este construită în două etape: mai întâi, ieșirea este realizată pe suprafața de fundal, iar apoi rezultatul este copiat de pe suprafața de fundal pe cea primară O tehnică similară este aplicată obiectelor DirectDraw pentru a suprima pâlpâirea în ieșire Următoarele sunt două metode care oferă rezultate în două etape în clasa KDirect D HRESULT KDirect D::Render(HWND hWnd) dacă ( ! m bReady ) returnează S OK: HRESULT hr = OnRenderO; dacă ( FAILED(h) ) întoarcere ora; hr = ShowFrame(hWnd); if ( h = DDERR SURFACELOST ) returnează RestoreSurfaces(); altfel ora de intoarcere: } HRESULT KD rect D::ShowFrame(HWND hWnd) { dacă (m bReady) { SetClientRect(hWnd): returnează m primary Blt(& m rcDest, m backsurface NULL DDBLT WAIT); } altfel returnează S OK; } Metoda KDirect D: :Render apelează mai întâi metoda virtuală OnRender, care realizează randarea reală, și apoi metoda ShowFrame, care copiază datele de pe suprafața de fundal pe cea principală Când rulați mai multe aplicații DirectX, memoria alocată unei suprafețe poate fi preluată de alte aplicații Programul verifică o stare de suprafață pierdută și restaurează toate suprafețele pierdute cu apeluri la IDirectDrawSurface?: -Restore Modul Direct D Direct Utilizarea Direct D într-o fereastră Clasa KDirect D a fost concepută ca o clasă generică care poate fi folosită oriunde Din acest motiv, tratarea mesajelor a trebuit să fie implementată într-o clasă separată Următoarea este o clasă de ferestre simplă care acceptă modul imediat Direct D clasa KD DWin : KWindow public, public KDirect DDemo { bool m bActive; HINSTANCE m hlnst: LRESULT WndProc(HWND hWnd UINT uMsg, WPARAM wParam LPARAM IParam) { switchC uMsg) { caz WM-CREATE: m hWnd = hWnd: m bActive = fals: dacă ( FAILED(ReCreate(m hInst, hWnd hWnd))) CloseWindow(hWnd); SetTimer(hWnd NULL); returnează : caz WM-PAINT: ShowFrame(hWnd): pauză: caz WM-SIZE: m bActive = (SIZE MAXHIDE!=wParam) && (SIZE MINIMIZED!=wParam): dacă ( m bActive && FAILED(OnResize(m hInst LOWORO(IParam) HIWORDOParam) hWnd hWnd)) ) CloseWindow(hWnd): pauză; caz WM-TIMER: dacă (m bActiv) Render(hWnd); întoarce ; cazul WM DESTROY: KillTimer(hWnd ): DescarcareO: PostQuitMessage(O): returnează OL; } returnează DefW ndowProc( hWnd uMsg, wParam IParam ): } void GetWndClassEx(WNDCLASSEX și wc) Capitolul DirectDraw și Direct D Immediate Mode { KWindow::GetWndClassEx(wc): wc style |= (CS-HREDRAW | CS VREDRAW): wc hlcon = Loadlcon(m hlnst, MAKEINTRESOURCE(IDI GRAPH)): } public: KD DW n(HINSTANCE hlnst) { m hlnst-hlnst: } }: Clasa KD DWin este declarată ca derivă din clasele KWindow (suport pentru ferestre generice) și KDirect D (suport Direct D) Mediul Direct D este inițializat când este procesat un mesaj WM CREATE, modificat când este primit un mesaj WM SIZE și distrus când este procesat un mesaj WM DESTROY Managerul WM PAINT extrage date de pe suprafața de fundal cu un simplu apel către KDirect D: :ShowFrame Clasa KD DWin creează un cronometru care controlează animația într-o fereastră Managerul de mesaje WM TIMER redă un nou cadru folosind metoda KDirect D: :Render Frecvența mesajelor temporizatorului depinde de arhitectura sistemului de operare Pe Windows / , programul nu primește mai mult de - mesaje timer pe secundă; pe Windows NT/ , pot fi primite până la de mesaje pe secundă Programele DirectX cresc de obicei ratele de cadre prin utilizarea buclelor pasive atunci când procesează mesajele Pe de altă parte, schimbarea buclei de mesaje a firului principal al programului nu este întotdeauna posibilă Într-o soluție alternativă, schimbarea cadrului este alocată unui fir de program separat Suprafețele de textura Principalele obiecte afișate de instrumentele Direct D - puncte, linii și triunghiuri - oferă rezultatul celor mai simple forme geometrice în spațiu unidimensional, bidimensional și tridimensional Pentru a face formele geometrice mai mult ca obiectele din lumea reală, Direct D vă permite să aplicați texturi triunghiurilor redate Harta de biți de textură trebuie mai întâi încărcată pe o suprafață de textură utilizată de Direct D O suprafață texturată este o suprafață în afara ecranului cu un raster încărcat Direct D acceptă mai multe variante de formate de bitmap de textură pentru a îmbunătăți performanța și a îmbunătăți capacitățile dispozitivului Aplicația trebuie doar să selecteze formatul de textură corect din lista de formate disponibile Metoda KOffScreenSurface: :CreateTextSurface de mai jos oferă cel mai simplu mod de a crea suprafețe texturate Crearea unei suprafețe texturate dintr-un raster necesită câțiva pași suplimentari HRESULT CALLBACK TextureCal back(DDPIXELFORMAT* pddpf vold * param) { // Găsiți un format simplu de textură >= biți/pixel Modul Direct D Direct lf ( (pddpf->dwFlags & (DDPFJ UMINANCE|DDPF BUMPLUMINANCE|DDPFJ UMPDUDV|DDPF ALPHAPIXELS)) ) lf ( (pddpf->dwFourCC - ) && (pddpf->dwRGBB tCount>= ) ) { memcpy(param, pddpf sizeof(DDPIXELFORMAT) ): return DDENUMRET CANCEL: // Opriți căutarea } return DDENUMRET OK: // Continuați } HRESULT KOffscreenSurface::CreateTextureSurface(IDirect DDev ce * pD DDev ce, IDirectDraw? * pDD, lățime nesemnată înălțime nesemnată) { // Solicitați informații despre capabilitățile dispozitivului D DDEVICEDESC ddDesc; HRESULT hr = pD DDevice->GetCaps(&ddDesc): if ( FAILED(hr) ) return hr; m ddsd dwFlags = DDSD CAPS | DDSD HEIGHT | DDSD WIDTH | DDSD PIXELFORMAT | DDSDJEXTURESTAGE: m ddsd ddsCaps dwCaps = DDSCAPS JEXTURE: m ddsd dwWidth = lățime: m ddsd dwHeight = înălțime: // Activați gestionarea texturii pentru dispozitivele accelerate hardware dacă ( (ddDesc deviceGUID =" IID IDirect DHALDevice) || (ddDesc deviceGUID == IID IDirect DTnLHalDevice) ) m ddsd ddsCaps dwCaps " DDSCAPS JEXTUREMANAGE: altfel m ddsd ddsCaps dwCaps |= DDSCAPS SYSTEMMEMORY: // Reglați lățimea și înălțimea dacă este necesar de către șofer if ( ddDesc dpcTriCaps dwTextureCaps & D DPTEXTURECAPS P W ) { pentru ( m ddsd dwWidth=l; lățime > m ddsd dwWidth; m ddsd dwWidth"=l ); pentru ( m ddsd dwHeight=l: înălțime > m ddsd dwHeight: m ddsd dwHeight"=l ): } dacă ( ddDesc dpcTriCaps dwTextureCaps & D DPTEXTURECAPSJQUARE NLY ) { if ( m ddsd dwWidth > m ddsd dwHeight ) m ddsd dwHeight = m ddsd dwWidth: else m ddsd dwWidth = m ddsd dwHeight: } memset(& m ddsd ddpfPixelFormat, O, sizeof(mjjdsd ddpfPixelFormat)): pD DDevice->EnumTextureFormats(TextureCal back, & m ddsd ddpfPixelFormat): Capitolul DirectDraw și Direct D Immediate Mode if ( m ddsd ddpfPixelFormat dwRGBBitCount ) returnează pDD->CreateSurface( & m ddsd & m pSurface, NULL ): else returnează E-FAIL; } Exemplu de mod Direct D Direct Deci, avem la dispoziție un mediu pregătit de clasele KDirect D și KD DWin și suport pentru rasterele de textură Pentru a implementa o fereastră Direct D, tot ce trebuie să faceți este să derivați o clasă din KDirect D și să suprascrieți câteva metode din ea Lista arată o clasă simplă de ferestre în mod imediat Direct D care afișează o piramidă rotativă Exemplul ilustrează lucrul cu texturi și Z-buffer, precum și crearea de animație Lista clasa KDirect DDemo : KDirect D public KOffScreenSurface m texture[ ]; public: HRESULT OnRender(voi d); HRESULT OnInit(HINSTANCE hlnst): HRESULT OnDescharge (nulat): }: HRESULT KD rect DDemo::OnInit(HINSTANCE hlnst) { D DMATERIAL mtrl ; memset(&mtrl sizeof(mtrl)); mtrl ambient r = l Of: mtrl ambient g = l Of: mtrl ambient b = l Of: m pD DDevice->SetMaterial( &mtrl ): m pD DDevice->SetRenderState( D DRENDERSSTATE AMBIENT RGBA MAKE( ) ); D DMATRIXmat; memset(& mat sizeof(mat)): mat ll = mat = mat = mat = l Of; // Vizualizare matrice unități în axa z D DMATRIX matView = mat: matView = Of; m pD DDevice->SetTransform( D DTRANSF RMSTATE VIEW &matView ); mat ll = Of; mat - Of; mat = l Of: mat = -O lf: mat = O Of; m pD DDevice->SetTransform( D DTRANSF RMSTATE PR JECTI N &mat); Modul Direct D Direct // Activează Z Buffer m pD DDevice->SetRenderState( D DRENDERSSTATE ZENABLE TRUE): pentru (int = : DrawPr mitive(D DPT TRIANGLELIST, D DFVF VERTEX, vârfuri, NULL): } HRESULT KDi rect DDemo::OnRender(void) timp dublu = GetTickCount() / : m pD DDevice->Clear( , NULL, D DCLEARJARGET | D DCLEAR ZBUFFER, RGBA MAKE(O, , Oxff ) l Of, ): lf ( FAILEDC m pD DDev ce->BeginScene() ) ) returnează E FAIL: D DMATRIX matLocal: memset(& matLocal, , sizeof(matLocal)); matLocal = matLocal = (FLOAT) cos( time ): matLocal = matLocal = (FLOAT) sin( time ): matLocal = matLocal = l Of: m pD DDevice->SetTransform( D DTRANSF RMDSTATE W RLD &matLocal ): m pD DDevice->SetTexture( , m texture[ ] ): DrawTriangle(m pD DDevice, , , , , - , , - , ): m pD DDevice->SetTexture( , m textureEU ): DrawTr angle(m pD DDevice, , , , - , - , , - , ): m pD DDevice->SetTexture( , m texture[ ] ): DrawTriangle(m pD DDevice, , - , - , , - , - ): m pD DDevice->SetTexture( , m texture[ ): DrawTriangle(m pD DDev ce, , , , , - , - , - ); m pD DDevice->EndScene(); returnează S OK: } Metoda OnRender umple suprafața dispozitivului Direct D cu o culoare albastră uniformă și resetează Z-buffer-ul folosind metoda IDirect DDevice ::Clear Ieșirea începe cu un apel la BeginScene și se termină cu un apel la EndScene Metoda interogează ora sistemului și o folosește pentru a ajusta matricea de rotație de-a lungul axei y Perioada de rotație este de aproximativ secunde ( x pi x ) Metoda redă apoi cele patru fețe ale piramidei, fiecare cu textura proprie Fețele piramidei sunt desenate ca triunghiuri în spațiul D Funcția de ajutor DrawTriangle obține trei puncte în spațiu în coordonate întregi Direct D folosește structura D DVERTEX pentru a reprezenta vârfurile necesare la desenarea punctelor, liniilor și triunghiurilor Rezultate Un vârf simplu conține coordonatele punctului, un vector normal și coordonatele texturii Coordonatele punctului definesc locația unui vârf în spațiu; vectorul normal specifică direcția suprafeței pe care se află punctul, iar coordonatele texturii determină poziția pixelului corespunzător pe rasterul texturii Când se aplică o textură, Direct D interpolează automat textura pentru fiecare pixel din triunghi Funcția DrawTriangle convertește coordonatele întregi în format de virgulă mobilă, calculează un vector normal de suprafață și setează coordonatele de textură fixe pentru fiecare vârf Datele sunt stocate într-o matrice D DVERTEX și redate cu un singur apel la IDirect DDevice: :DrawPrimitive, metoda principală de randare pe dispozitivele Direct D Pe fig prezintă unul dintre cadre în timpul rotației piramidei Orez Exemplu de mod Direct D Direct Datorită capacităților bogate ale modului imediat al Direct D, programarea pentru acesta este o sarcină prea complexă pentru a fi descrisă în detaliu în paginile acestei cărți Consultați documentația Microsoft DirectX pentru un tutorial bun și exemple de programe Rezultate Acest capitol a introdus elementele de bază ale programării pentru modul direct DirectDraw și Direct D Am acoperit procesul de creare a claselor C++ Capitolul DirectDraw și Direct D Immediate Mode pentru suport generic DirectDraw/Direct D Aceste clase sunt separate de mânerul ferestrei, astfel încât să se poată integra cu orice fereastră În partea DirectDraw, am abordat în detaliu cum să folosiți metoda Bit DirectDraw pentru ieșirea accelerată hardware, cum să lucrați direct cu o suprafață fixă și cum să apelați la GDI pentru ajutor Pe parcurs, au fost dezvoltate clase și metode pentru lucrul cu suprafețe off-screen, suprafețe de textură, buffer-uri Z și suprafețe de font, precum și pentru ieșirea textului Sper că autorul a reușit să demonstreze că programarea pentru DirectDraw/Direct D nu este o sarcină atât de dificilă, mai ales cu clase C++ bine concepute Domeniul de aplicare al DirectDraw/Direct D nu se limitează la jocuri și programe educaționale Aplicațiile obișnuite cu ferestre pot profita și de suportul hardware DirectDraw/Direct D pentru a îmbunătăți calitatea ieșirii și a face interfața cu utilizatorul mai ușor de utilizat Microsoft oferă documentație bună, tutoriale și exemple de programe pentru DirectDraw, modul imediat Direct D și alte componente DirectX Documentația și tutorialele pot fi găsite pe MSDN, iar exemple de programe pot fi găsite în Platform SDK și DirectX SDK Microsoft oferă, de asemenea, o bibliotecă de clasă pentru construirea de aplicații în mod direct Direct D; În centrul acestei biblioteci este clasa CD DApplication Codul se află în subdirectoarele Include și Src\D DFrame din directorul Samples\MultiMedia\D DIM al SDK-ului Clasele Direct D ale Microsoft nu au fost folosite în acest capitol deoarece îmbină strâns aplicația, fereastra și suportul DirectDraw/Direct D Această bibliotecă vă permite să creați aplicații cu o singură fereastră care acceptă Direct D Chiar și bucla de mesaje folosește o variabilă globală pentru a transmite mesaje managerilor virtuali definiți în clasa CD DApplication Biblioteca include o clasă foarte utilă pentru lucrul cu texturi, dar nicio clasă pentru suport general pentru suprafețele DirectDraw Există și o clasă extrem de utilă pentru încărcarea fișierelor DirectX în format X (formatul Microsoft pentru reprezentarea modelelor D) În general, biblioteca conține mult cod util, dar pentru a include suportul Direct D într-un program de fereastră C++ finit, va trebui să munciți din greu pentru a-l adapta Tehnologia DirectX? apărut relativ recent La momentul scrierii acestui articol, nu există manuale bune de recomandat Este posibil să aveți nevoie de o carte bună despre OpenGL, împreună cu documentație, tutoriale și exemple de la Microsoft, deoarece modul imediat al Direct D are multe în comun cu OpenGL Exemple de programe Capitolul este însoțit de trei programe și mai multe clase pentru lucrul cu DirectDraw și modul direct Direct D (Tabelul ) Rezultate Tabelul Programe capitolul Descriere director de proiect Samples\Chapt \ddbasic Demonstrarea caracteristicilor de bază DirectDraw Samples\Chapt \DemoDD Utilizarea DirectDraw pentru a afișa în ferestre MDI copil, pentru a desena pixeli, linii și forme închise, pentru a afișa bitmap-uri, sprite și text Samples\Chapt \DemoD D Utilizarea modului Direct D Direct în fereastra SDI, lucrul cu o suprafață secundară, Z-Buffers și suprafețe texturate Index alfabetic ȘI AbortDoc AbortPrinter, AddFontMemResourceEx, AddFontResource, Adobe Type Manager (ATM), AdvancedDocumentProperties, AlphaBlend, ALTERNAT, modul de umplere, , Arc unghiular, , ANSI-CHARSET, CALITATE ANTIALIASĂ, , AppendMenu, ARAB-CHARSET, Arc, ArcTo, LA BALTIC-CHARSET, BeginPaint, , - BeginPath, , , , , BitBlt, , , , BITMAP, structura, DER, OREHEAPC structura, BITMAFILEHEADER, structura, , BITMAPINFO, structura, , , , , BITMAPINFOHEADER, structura, , , , BITMAPV HEADER, structura, , BITMAPV HEADER, structura, , BITSPIXEL, NEGRU/ALB, BltBatch, BltFast, , , Format BMP titlu, măști, matrice de pixeli, tabel de culori , Borland C++, BoundsChecker (NuMega), , Break Char PERIE, structura, Cu C/C++, , C++, nume de clase, CallNextHookEx, CAPTUREBLT, steag, CGdiObject, CHINESEBIG CHARSET, Chord, , ClientToScreen, CLIPCAPS, CLIPOBJ, structura, CloseEnhMetaFile, CloseFigura, vechi, tabel, COLOR GRADIENTINACTIVE- CAPITOLUL BARĂ DE DEFIRE CULOARE, COLORREF, , , , COM (Model de obiecte componente), , CombineRgn, COMMCTRL DLL, REGIUNEA COMPLEX, CopyEnhMetaFile, Copiere în Clipboard, CreateBitmap, , CreateBitmapIndirect, CreateBitmapSurface, CreateBrushIndirect, CreateCompatibleBitmap, Index alfabetic CreateCompatibleDC, CreateDC, , CreateDIBitmap, CreateDIBPalette, CreateDIBPatternBrush, CreateDIBPatternBrushPt, CreateDIBSection, CreateDiscardableBitmap, CreateEllipticRegion, , CreateEllipticRegionIndirect, CreateEnhMetafile, , CreateEvent, CreateFile, Create Font, CreateFontIndirect, CreateFontIndirectEx, , Create HalftonePalette, , CreateHatchBrush, CreatelC, CreatePatternBrush, CreatePen, , CreatePenIndirect, CreatePolygonRgn, CreatePrimary Surface, CreateRectRgn, , CreateRoundRectRgn, CreateScalableFontResource, CreateService, CreateWindow/CreateWindowEx, , CS (segment de cod), CURVECAPS, D D DVERTEX, structură, DD SURFACE INT, structură, DD SURFACE LOCAL, structura, DD SURFACE MORE, structura, DDA, algoritmi, DDBLTFX, structură, DDCOLORKEY, structură, DDCREATE EMULATEONLY, DDCREATE HARDWAREONLY, DDI, interfață, DDK (kit de drivere de dispozitiv), DDPIXELFORMAT, structura, ddraw dll, DDSURFACEDESC , structura, DEFAULT CHARSET, , DEFAULT-PITCH, DefWindowProc, DeleteEnhMetaFile, DeleteObject, , , , Delphi, DESIGNVECTOR, structura, DEVLEVEL, structura, DEVMODE, structura, , DIBSECTION, structura, DIB-sectiuni CreateDIBSection, GetDIBColorTable, SetDIBColorTable, General, , Direct D, , DirectAnimation, DirectDraw, , , , HAL, HEL, IDirectDraw, interfață, , IDirectDrawClipper, interfață, IDirectDrawColorControl, interfață, IDirectDrawGammaControl, interfață, IDirectDrawPalette, interfață, IDirectDrawSurface, interfață, IDirectDrawSurface?, interfață, IDirectDrawVideoport, interfață, arhitectură, acces direct pixeli, structuri de date, DirectInput, DirectMusic, DirectPlay, Direct Setup, DirectShow, DirectSound, DirectX, , DllGetC , Documents , DirectX Index alfabetic DRVENABLEDATA, DS (segment de date), DSTINVERT, dumpbin exe, E EASTEUROPE CHARSET, EDDDIRECTDRAWCLOBAL, structura, EDD DIRECTDRAW LOCAL, structura, EDD SURFACE, structura, Elipsa, , EMF (metafișiere îmbunătățite), , , redare, înregistrări, tipuri de înregistrări nedocumentate, palete, text, traiectorii, Clipboard gol, EMRBITBLT, Structură, EndDoc, EndPage, endPath, , , ENHMETAHEADER, structura, EnumDisplayDevices, EnumDisplaySettings, EnumEnhMetaFile, Imprimante enumerate, EnumFontFamiliesEx, ENUMLOGFONTEXW, structura, EnumObjects, , EnumSystemCodePages, EPALOBJ, structura, EqualRegion, ETO CLIPPED, ETO GLYPH INDEX, ETOJGNORELANGUAGE, ETO NUMERICSLATIN, ETO NUMERICSLOCAL, ETO OPAQUE, ETO PDY, ETO RTLREADING, ExtCreatePen, ExtCreateRegion, , EXTLOGFONTW, structura, EXTLOGPEN, structura, ExtSelectClipRegion, ExtTextOut, , , F FD GLYPHSET, structură, FF DECORATIVE, FF DONTCARE, FF MODERN, FF ROMAN, FF SCRIPT, FF SWISS, FillPath, , , FillRect, , FillRgn, , GăsițiResurse, FirstChar, FIX, structura, FIXED PITCH, FlattenPath, , FLOATOBJ, structura, extensia FNT FON, extensie, FONTEDIT, utilitate, FONTOBJ, structura, G GCPJUSTIFY, steag, GCP REORDER, semnalizare, GCPJJSEKERNING, steag, GDI, , API OpenGL, arhitecturi, manipulatoare, funcții nedocumentate, obiecte, DLL-uri de sistem, funcții exportate, GDI+, GDI DLL, , , GetAspectRatioFilterEx, GetBkColor, , GetBkMode, GetBoundsRect, GetCharABCWidthFloat, GetCharABCWidthl, Index alfabetic GetCharABCWidths, GetCharacterPlacement, , GetCharWidth , GetCharWidthl, GetClientRect, GetClipboardData, GetClipBox, GetClipRgn, GetCurrentObject, GetCurrentProcessId, GetDC, , GetDCBrushColor, GetDCOrgEx, GetDCPenColor, GetDefaultPrinter, GetDeviceCaps , , , GetEnhMetaFileBits, GetEnhMetaFileHeader, GetGlyphlndices, , GetKerningPairs, GetMetaRgn, GetNearestColor, GetNearestPalettelndex, GetObject, GetObjectType, , GetPaletteEntries, GetPath, , GetPathData, GetPixel, , , GetPolyFillMode, GetPrinter, , GetRandomRgn, - GetRegionData, GetROP , GetStockObject, GetSurfaceDesc, GetSysColor, GetSysColorBrush, GetTabbedTextExtent, GetTextABCWidths, GetTextABCWidthsFloat, GetTextCharacterExtra, GetTextCharSet, GetTextCharSetInfo, GetTextExtentPoint , GetTextFace, GetUpdateRegion , GetWindowDC, GetWindowRect, GGO BEZIER, , GGO BITMAP, GGO GLYPH INDEX, GGO GRAY BITMAP, GGO GRAY BITMAP, GGO GRAY BITMAP, GGO METRICS, GGO NATIVE, GGO UNHINTED, GIF, format, glyf, tabel, , GLYPHINFO, tabel, GLIFMETRICĂ, structură, Structura GRADIENT RECT Structura GRADIENT TRI ANGLE Umplere cu degrade, GREEK CHARSET, GUID, H HAL, MANEBIL, structura, HANGUL CHARSET, HBITMAP, , HBRUSH, , HDC, CHARSET EBRAU, HEL, HENHMETAFILE HFONT, HGDIOBJ, , , HGLOBAL, INSTANȚĂ, HLS, spațiu de culoare, , HMENU, HMODULE, HORZRES DIMENSIUNEA HORZ HPEN, , HWND, eu IClassFactory, interfață, ICM (Image Color Management), IDirect D , interfață, IDirectDraw, interfață, IDirectDraw , interfață, IDirectDraw?, interfață, Index alfabetic IDirectDrawClipper, interfață, , IDirectDrawColorControl, interfață, IDirectDrawGammaControl, interfață, IDirectDrawPalette, interfață, IDirectDrawSurface, interfață, IDirectDrawVideoport, interfață, IFIMETRICS, structură, IMAGEJDOS-HEADER, IMAGE NT HEADERS, IMAGE OPTIONAL HEADER, Rect InsertMenuItem, IntersectRect, InvertRect, InvertRgn, , IUnknown, interfață, J JOHAB CHARSET, JPEG, La KERNEL DLL, , , L TQC t" C'' li QV ^Q LAYOUT BITMAPORIENTATION- PRESERVED, LAYOUT RTL, LFONT, structură, LINEATTRS, structură, LINECAPS, LineDDA, LineDDAProc, LineTo, LoadBitmap, , Loadlmage, sursa, tabel, Loadlmage, structură, RU, RU, RU , , , LOGFONT, structura, , LOGFONTW, structura, LOGPALETTE, structura, , LOGPEN, structura, LOGPIXELX, LOGPIXELY, LPDIRECTDRAW, LPDIRECTDRAWSURFACE, LPtoDP, , M MAC CHARSET, MAKEROP , macro, MaskBIt, MAT , structura, MDI (document multiplu) interfață), MERGECOPY, , MERGEPAINT, METAFONT, MFC (Microsoft Foundation Clasele), , Baza de cunoștințe Microsoft, Microsoft Word, MM ANISOTROPIC, modul de afișare, , MM HIENGLISH, mod afișaj, MM HIMETRIC, mod afișaj, Modul MMJSOTROPIC afișaj, Modul MM LOENGLISH afișaj, MM LOMETRIC, mod afișaj, MM TEXT, modul de afișare, , , , MM TWIPS, modul de afișare, MozheToEx, , MSDN (Microsoft Developer reţea), Multiple Mașter OrepTure, fonturi, N Next Band, nmnlzp pvp NOMIRRORBITMAP, steag, , NOTSRCCOPY, NOTCERASE, Index alfabetic Novell Netware, Furnizor de imprimare, NTFS (sistem de fișiere NT), NTOSKRNL EXE, NULL, regiune de tăiere, NULLREGION, NUMCOLORS, O OBJ ENHMETAFILE, OEM CHARSET, OffsetClipRgn, OffsetRgn, OffsetViewportOrgEx, O L E , OnDraw OPAC, modul de umplere a fundalului, OpenGL, , OpenType, fonturi, OUTLINETEXTMETRIC, structura, , - R PAGESETUP, structura, PageSetupDlg, PaintRgn, , PAINTSTRUCT, structura, PALETA PALETTEENTRY, structura, PALETTEINDEX, , PALETTERGB, , PALOBJ, structura, PANOSE, sistem de înlocuire a fonturilor, PANOSE, structura, PatBlt, , PATCOPIE Structura PATH Structura PATHDATA Structura PATHDEF Structurile PATHDT Structura PATHOBJ PathToRegion PATINVERT PATPAINT PCL- PCX- PDEV, structura, PDEV WIN K, PE, format de fișier executabil, , PFE, structura, PFF, structura, PFT, structura, Placinta Avioane PlayEnhMetaFile, , , - , PlayEnhMetaFileRecord, PlgBlt, , , PNG, format, PUNCTUL, structura, , , PolyBezier PolyBezierTo, PolyDraw, , , POLYGONALCAPS, PolyLine către, Poligon, , PolyPolyline, PolyTextOut, PostScript, , Band Band, PrintDialog, PrintDlg, , PRINTDLG, structura, - PrinterProperties, profile exe, PS ALTERNATE, , PS COSMETIC, PS DASH, PS DASHDOT, PS DASHDOTDOT, PS DOT, PS ENDCAP FLAT, PS ENDCAP ROUND, PS ENDCAP SQUARE, PS GEOMETRIC, PSJNSIDEFRAME, PS JOIN BEVEL, PSJOIN MITER, PSJOIN ROUND, PS NULL, PS SOLID, PS USERSTYLE, PT CLOSEFIGURE, Q Querylninterface, QuickDraw GX (Apple), Index alfabetic R R MASKPEN, , , R MERGEPEN, R NOP, R NU, R NOTCOPYPEN, R NOTXORPEN, R ALB, R XORPEN, RASTERCAPS RAW, format spool, RC BITBLT, RC-PALETTE, RDTSC, instrucțiuni procesor, RealizePalette, rebase exe, RECT, structura, , , Dreptunghi RectlnRegion, REGIUNEA, structura, , REGIONOBJ, ReleaseDC, RemoveFontResource, RemoveFontResourceEx, RestoreDC, RFONT, structura, RGB, spațiu de culoare, , RGBQUAD, structură, RGBTRIPLE, structură, , RGNDATA, structura, , RoundRect, ENGLISH CHARSET, s SaveDC, SCAN, structura, , SelectClipPath, SelectClipRgn, , Selectați obiect, , SelectPalette, , Selectați regiunea, SetAbortProc, SetBkColor, , , SetBkMode, , SetBoundsRect, SetBrushOrgEx, SetClipboardData, SetClipPath, SetClipper, SetClipRgn, SetDCPenColor, , SetDIBColorTable, , SetDIBitsToDevice, SetEnhMetaFileBits, SetMenuItemBitmaps, SetMenuItemInfo, , SetMetaRgn, , SetMiterLimit, SetPixel, , , SetPixelV, SetPolyFillMode, SetRect, SetRectRgn, SetROP , SetSourceColorKey, SetStretchBltMode, SetSysColor, SetTextAlign, SetTextCharacterExtra, SetTextColor, SetTextJustification, SetViewportExtEx, SetWindowExtEx, SetWindowRgn, , , SetTextJustification, SIM Hook, SetTextWindowExtExt, SetTextWindowExtExt, SIM W SPOOLSV EXE, SPRITESTATE, structură, , Spy++, SRCAND, SRCCOPY, SRCINVERT, SRCPAINT, SS (Segment de stivă), StartDoc, Pagina de pornire, STI (Still Image) API, STM SETIMAGE, Message, STRETCH ANDSCANS, STRETCHJDELETESCAN, STRETCH-HALFTONE, STRETCH ORSCANS, StretchBlt, , , , , StretchJDELETESCAN, STRETCH-HALFTONE, STRETCH ORSCANS, StretchBlt, , , , , , , , , , , , , , Index alfabetic StrokePath, , SubtractRect, SUCCESED, macro, SUPRAFAȚA SURFOBJ SYMBOL CHARSET, T TA BASELINE, TA BOTTOM, TA CENTER, TA LEFT, TANOUPDATECP, TA DREAPTA, TA RTLREADING, TA TOP, TA UPDATECP, TabbedTextOut, TBBBUTON TEXT, format spool, software TEXTCAPS, TEXTMETRIC, structură, , TextOut, , THAI CHARSET, TIFF, format, TRANSPARENT, modul de umplere a fundalului, TransparentBIt, , TRIVERTEX, structură, TrueType, fonturi, instrucțiuni, tabel PostScript, nume, kerning, format , TT PRIM CSPLINE, TT PRIM LINE, TT PRIM QSPLINE, TTPOLYCURVE, structură, TTPOLYGONHEADER, structura, CHARSET TURC, și Unicode, , , UniDriver UNIDRVUI DLL, Uniscribe, USER DLL, , , V VARIABLE PITCH, VERTRES VERSIUNEA VIETNAMESE CHARSET, Visual Basic, , Visual C++ VTune (Intel), w WidenPath, , WIN K SYS, , WinDbg, DEBINAR, modul de umplere, Windows NT / , WINSPOOL DRV, WM CREATE, mesaj, , WM DETROY, mesaj, WM DISPLAYCHANGE, mesaj, WM ERASEBKGND, mesaj, WMFONTCHANGE, mesaj, WMJNITDIALOG, mesaj, WM MOUSEMOVE, mesaj, WM NCPAINT, mesaj, WM PAINT, mesaj, , , WMPALETTECHANGED, mesaj, , WMPALETTEISCHANGING, mesaj, WMQUERYNEWPALETTE, mesaj, WM SIZE, mesaj, WNDCLASSEX, structură, WriteFile, WritePrinter, , WS EX LAYOUTRTL, W S EX DREAPTA, z Z-tampon, , Z-spălare, Index alfabetic spațiu de adrese în modul kernel, acces, algoritmi de conversie a culorilor raster, canal alfa, alfa suprapunere simulată, generală, hărți de biți dependente de dispozitiv (DDB) CreateBitmap, CreateBitmapIndirect, CreateCompatibleBitmap, CreateDIBitmap, LoadBitmap, de pixeli, matrice generală dependentă de dispozitiv, , dependente de dispozitiv, bitmaps (DIB) SetDIBitsToDevice, StretchDIBits, ieșire, conversie format de culoare, operațiuni raster, scriere arabă, arhitectură GDI, Windows, Sisteme grafice Windows, sisteme de imprimare, asamblare, transformări afine asociativitate, închideri, curbe Bezier, linii, inverse, informații generale, paralelism, proprietăți de identitate, rastere, , elipse, B Linia de referință, Beziers, raster de operații binare, cu regiuni, blitting, Bresenham, algoritm, LA fonturi vectoriale, adaptor video, memorie virtuală, decalaj exterior, suprafață în afara ecranului, decalaj interior, justificare, aliniere text, G corecție gamma, stilouri geometrice, histogramă, glife index în tabel, de caractere chirilice, definiții, de pixeli principali, de decodare de contur, de pixeli de fundal, de umpleri cu gradient, în spațiul HLS, radial, moduri, d dump, fonturi decorative, drivere I/O, moduri kernel, dispozitive Microsoft Windows, sistem de fișiere, ecran, arcuri AngleArc, Arc, ArcTo, informații generale, Index alfabetic definirea arcelor (^continuare) în grade, conversie în curbe Bezier, forme închise umpleri gradient, umbrire, trasee închise, perii, poligoane, informații generale, dreptunghiuri, regiuni, segmente, sectoare, umpleri cu textură, elipse, Și încapsulare, instrucțiuni pentru glife, Internet, indicator de interfață, context de informații despre dispozitiv, partea executivă, curbe Bezier pătratice, cuantizări după arbore octant, culori, operațiuni raster cuaternare, kerning, perii LOGBRUSH, structură, punct de bază, boolean, obiect, general, personalizat, culori de sistem, standard, zonă client, Knuth, Donald, colecții de fonturi, compilator , context dispozitiv , Windows , Atribute, Informațional, Metafișier, General, Obține informații despre capacitate, Părinte, Link ferestre, Compatibil, Creare, Sumă de verificare, , Pixuri cosmetice, Curbe PolyBezier PolyBezierTo, PolyDraw, invarianță afină, divizibilitate, informații generale, , transformare arc, L ligatură, linii, , palete logice, paletă implicită, paletă semiton, fonturi logice, CreateFont, CreateFontIndirect, CreateFontIndirectEx, LOGFONT, structură, spațiu exterior, spațiu interior, greutăți simulate, metrici ABC, spațiere superlinie, spațiere sublinie, spațiere sublinie, furnizare spațiere sublinie, m Mandelbrot, set, manipulatori, , Index alfabetic matrice de pixeli, metafișiere, , context dispozitiv metafișier, metafișiere, EMF redare, înregistrări, tipuri de înregistrări nedocumentate, palete, text, traiectorii, WMF (Windows Metafiles), microkernel, minidrivere, poligoane, , filtre morfologice, n spațiere în superscript, O regiune actualizabilă, orientată pe obiecte programare, clase, manipulatoare, obiecte de bază, perii uniforme, tăiere operatii binare cu regiuni, vizibilitate, regiuni de actualizare, informații generale, , regiuni Rao, regiuni de sistem, P palete, algoritmul lui Floyd Steinberg, în EMF, cuantificarea culorilor, logic, paleta principală, palete (continuare) implementare, paletă de sistem, mesaje, paletă de fundal, paralelograme, blitting, , pixuri, logic, extins, standard, imprimare, arhitectură , driver de imprimantă , sistem de coordonate logic , procesor de imprimare , ieșire directă către port, raster, casete de dialog standard, pixeli, , tăiere, culori, înlocuire font, spațiere între rânduri, lățime completă, , umplere translucidă, palete semitonuri, furnizor de imprimare, defilare, filtre spațiale, procesoare de imprimare PSCRIPT , destinație, R desktop, ieșire, umpleri cu gradient radial, Rao, regiune, grafică raster, perii bitmap, operații, codare, fonturi, , rastere DIB-section, GIF, format, JPEG, format, TIFF, format, dependent de dispozitiv (DDB), Index alfabetic bitmaps {continuare) independent de dispozitiv (DIB), transformări afine, la EMF, imprimare, comenzi de meniu de etichetare, filtre spațiale, contexte de dispozitiv compatibile, vârfuri extinse, palete de realizare, regiune, în EMF, contextul dispozitivului, metaregiune, ferestre, tăiere, , primirea datelor, Rao, sistem, crearea obiectelor, moduri umplere fundal, ferestre, afișare MM ANISOTROPIC, , MM HIENGLISH, MM HIMETRIC, MMISOTROPIC, MM LOENGLISH, MM LOMETRIC, MMJTEXT, , , , , , , MM, parent device, parent device TI WIPS context TIPS segment, sector, font-family, paletă de sistem, procese de sistem, regiune de sistem, , sisteme de coordonate în EMF, global, , pagini, dispozitive, fizice, context compatibil dispozitive, spooler , mediu de programare , perii standard, pixuri, culori statice, alocarea sistemului de coordonate pagini, moduri de afișare, T twips, de bitmap-uri de textură, de texturi, de operații de bitmap ternare, NEGRU/ALB, DSTINVERT, MERGECOPY, MERGEPAINT, NOTSRCCOPY, NOTSCERASE, PATCOPY, PATINVERT, SRCAND, , , SRCERASE, SRCINVERT, , SRCPAINT, listă, căi, în EMF, închis, obține date, build, gradient triunghiular de umplere, La indicatori și mânere, scad adâncimea de culoare a unui raster, rastere DIB impachetate, F fabrica clasa, Algoritmul Floyd-Steinberg, Index alfabetic paleta de fundal, formatarea textului, c culoare de fundal, taste de culoare, w lățimea caracterelor, fonturi, Font Smart Homage Page (HP), PANOZA tipul adevărat TrueType/OpenType, în GDI, glife, fonturi (continuare) codificare, logic, monospațiu, obține informații, bitmap, familii, instalație, dispozitive, perii de linie, uh elipse, , EU SUNT limbaj de descriere a paginii (PDL), monitoare de limbă, EDITURA REZERVĂ SPECIALISTI AFACERI! STIMATI DOMNI! EDITURA „PITER” VA INVITĂ LA COOPERARE RECIPROC BENEFICĂ OFERIM O GAMĂ EXCLUSIVĂ DE LITERATURĂ INFORMATICĂ, MEDICALĂ, PSIHOLOGICĂ, ECONOMICĂ ȘI POPULARĂ SUNTEM PREGĂTIȚI SĂ LUCRĂM PENTRU DVS NU NUMAI ÎN ST PETERSBURG REPREZENTAȚII NOASTRE SUNT LA MOSCOVA, MINSK, Kiev, HARKOV PENTRU INFORMAȚII SUPLIMENTARE VA RUGAM CONTACTA URMĂTOARELE ADRESE: Rusia, Moscova Reprezentanța editurii „Piter”, m „Kaluzhskaya”, st Butlerova, , of și , telefax ( ) - - E-mail: sales@piter msk ru Ucraina, Harkov Reprezentanța editurii „Peter”, tel ( ) - - , fax: ( ) - - , - - Adresă poștală: , Harkov, PO Box E-mail: piter@tender kharkov ua Rusia, Sankt Petersburg Reprezentanța editurii „Piter”, m „Elektrosila”, st Blagodatnaya, d , tel ( ) - - - - E-mail: sales@piter com Ucraina, Kiev Filiala reprezentanței Harkov a editurii „Petru”, tel /fax: ( ) - - , - - Adresă pentru scrisori: , Kyiv- , PO Box Adresă actuală: , Kiev, Krasnykh Kazakov Ave , , bldg unu E-mail: office@piter-press kiev ua Belarus, Minsk Reprezentanța editurii „Piter”, tel /fax ( ) - - Adresă poștală: , Minsk, st Kuibyshev, de ani SRL „Peter M”, librăria „Evrika” E-mail: peterbel@tut by FIECARE DINTRE ACESTE REPREZENTĂRI FUNcționează CU CLIENȚI CONFORM STANDARDUL UNIC AL EDITURII „PITER” Cautam parteneri straini sau intermediari cu acces pe piata externa Telefon de contact: ( ) - - E-mail: grigorjan@piter com Editorii de literatură informatică, psihologică, economică, juridică, medicală, educațională și populară (de sănătate și psihologie) ai Editurii Piter invită autorii să coopereze Contact telefonic: Sankt Petersburg - tel ( ) - - , Moscova - tel : ( ) - - , - - EDITURA STIMATI DOMNI! PUTEȚI ACHIZIȚIONARE CĂRȚI ALE EDITURII „PITER” EN-GROS ȘI CU AMANTUL DE LA PARTENERII NOȘTRI REGIONALI Bashkortostan Ufa, „Asia”, st Zentsova, d (en-gros), mag „Oaza”, st Chernyshevsky, d , tel /fax ( ) - - E-mail: asiaufa@ufanet ru Orientul îndepărtat Vladivostok, „Primorsky Trading House of the Book”, tel /fax ( ) - - Adresa poștală: , Vladivostok, str Svetlanskaya, de ani E-mail: bookbase@mail primorye ru Khabarovsk, Mirs, tel ( ) - - , fax - - Adresa poștală: , Khabarovsk, st Kim Yu Chen, de ani E-mail: postmaster@bookmirs khv ru Khabarovsk, „Lumea cărților”, tel ( ) - - , fax - - Adresă poștală: , Khabarovsk, st Karl Marx, de ani E-mail: postmaster@worldbooks knt ru regiunile europene ale Rusiei Arhangelsk, „Casa cărții”, tel ( ) - - , fax - - Adresa poștală: , mp Lenina, E-mail: book@atnet ru Kaliningrad, Vester, tel /fax ( ) - - , - - Adresă poștală: , Kaliningrad, st Victory, d Magazin „Cărți și cărți mici” E-mail: nshibkova@vester ru; www vester ru Rostov-pe-Don, PBOYuL Ostromensky, Sokolova Ave , , tel /fax ( ) - - E-mail: ostrom@don sitek net Caucazul de Nord Essentuki, Rossy, st Oktyabrskaya, , tel /fax ( ) - - E-mail: rossy@kmw ru Siberia Irkutsk, „Vând”, tel ( ) - - , fax - - Adresa poștală: , Irkutsk, st Baikalskaya, , căsuța poștală E-mail: prodalit@irk ru; http://www prodalit irk ru Irkutsk, „Antey-kniga”, tel /fax ( ) - - Adresă poștală: , Irkutsk, st Karl Marx, E-mail: antey@irk ru Krasnoyarsk, „Lumea cărților”, tel /fax ( ) - - Adresă poștală: , Krasnoyarsk, Prospekt Mira, E-mail: book-worid@public krasnet ru Nijnevartovsk, Casa Cărților, tel ( ) - - , fax - - Adresă poștală: , Nijnevartovsk, Pobedy pr , E-mail: book@nvartovsk wsnet ru Novosibirsk, „Cartea de top”, tel ( ) - - , fax - - Adresă poștală: , Novosibirsk, PO Box E-mail: office@top-kniga ru; http://www top-book ru Tyumen, „Drog”, tel /fax ( ) - - , - - Adresa postala: , str Respubliki, E-mail: drug@tyumen ru Tyumen, „Foliant”, tel ( ) - - , fax - - Adresă poștală: , Tyumen, st Harkovskaia, d a E-mail: foliant@tyumen ru Tatarstanul Kazan, „Tais”, tel ( ) - - , fax - - Adresa poștală: , Kazan, str Paznici, d a E-mail: tais@bancorp ru Ural Ekaterinburg, magazinul numărul , st Chelyuskintsev, , tel /fax ( ) - - E-mail: gvardia@mail ur ru Ekaterinburg, „Valeo-book”, st Klyuchevskaya, d , tel ( ) - - , fax - - E-mail: valeo@etel ru Fen Yuan Programare grafică pentru Windows FI PETER i p v e nt PH PTR Programare grafică PENTRU fereastră? Cartea este dedicată programării grafice pentru Windows și conține informații serioase, complete, la zi, de încredere și practice Această carte serioasă nu se oprește la nivelul unei descrieri generale a funcțiilor API, ci acoperă în detaliu conceptele arhitecturale ale acestora, structurile de date interne și principiile de implementare Această carte cuprinzătoare și actualizată se concentrează pe cea mai bună implementare actuală a API-ului Win , Windows , baza viitoarelor sisteme de operare ale Microsoft și descrie noile sale caracteristici Această carte autorizată se bazează pe studii experimentale ale API-ului Win și pe o revizuire riguroasă a tuturor informațiilor Această carte practică nu este doar o descriere a API-ului și a exemplelor banale Se concentrează pe sarcini practice; conține cod de program care poate fi utilizat în programe reale; oferă cititorului utilități utile și îl ajută să scrie programe profesionale Vizitați magazinul nostru web: http://www piter com